Spatial SQL

Parallel SQL Power for ArcGIS® Pro

GIS is about Spatial Data

Spatial SQL is the world's best tool for manipulating spatial data, and SQL for ArcGIS® Pro is built upon the the world's richest, fastest, and most powerful desktop spatial SQL engine ever, Manifold's massively parallel Radian® spatial database platform. ArcGIS Pro users can now use the world's best spatial SQL with file geodatabases and other data sources.

The add-in includes hundreds of spatial SQL functions for vectors, rasters, and attribute data, that fill every spatial need in GIS, ETL and spatial data analytics.

Special introductory offer: Only $145. The world's most advanced desktop spatial SQL is only $145. Amazing! The fastest and most powerful SQL ever created for Pro now also has the world's lowest cost of ownership.

It's a Database World

Far more than just a client, the SQL for ArcGIS Pro engine includes a powerful, internal database and SQL query engine expressly built to handle the large, complex operations characteristic of spatial data and spatial data engineering. The SQL query engine and database were created from the ground up to automatically run queries with massive CPU and GPU parallelism. SQL's raw speed and massively parallel performance enable you to accomplish spatial SQL magic on the desktop with bigger data in seconds or minutes, and not hours or days. That same, raw speed lets SQL for ArcGIS Pro keep up with Enterprise data servers as a client for more effective use of your organization's data.

"That EXECUTE [[....]] statement still has me smiling. I now find myself mixing and matching SQL Server, PostGIS, SpatiaLite, and [SQL for ArcGIS Pro] on a daily basis. I think knowing how to integrate SQL Server with [SQL for ArcGIS Pro] is a killer skill in the Microsoft ecosystem. " - Forum post

Our Kind of Data

The SQL for ArcGIS Pro database engine was designed from the ground up to handle spatial data in all the forms you will need: vector data, raster data, curvilinear objects, Z data, multichannel data and any pixel type. Specialized infrastructure, like an exceptionally rich selection of dedicated indexes, guarantees the fastest possible pipeline between parallel data access and massively parallel algorithms. The query engine automatically optimizes queries on the fly for the special needs of spatial data types and parallel algorithms.

It's all under the hood so when you step on the gas the system roars. Point it where you want to go and SQL for ArcGIS Pro does the rest.

Be Friends with Everybody

The world's spatial data - your spatial data - hangs out in a host of database servers, file databases, web server sources and hundreds of file formats. By default, SQL for ArcGIS Pro automatically connects to all file geodatabases used in your ArcGIS Pro project. In Advanced mode, SQL connects to everything. Better still SQL for ArcGIS Pro connects to and works with multiple sources. Transfer and blend data from multiple sources at once. Write SQL to move data directly from SQLite into PostgreSQL:

SELECT * INTO [postgresql_connection]::[public.roads] 
FROM [sqlite_connection]::[roadtable]
"Because I can use a command window to write native queries [SQL for ArcGIS Pro] is effectively a client for Postgresql, or indeed any other DBMS - I no longer need to rely on PGAdmin." - Forum post

Everything is Exposed

SQL for ArcGIS Pro exposes all aspects of data manipulation within the internal database, and thus to any queries you write. All tiles and geometry, every pixel and every coordinate system, every attribute, every property, every bit of metadata, all of it is at your fingertips to manipulate with SQL. Extensive SQL functions for coordinate systems and other infrastructure make it easy to hammer vast quantities of data into exactly the form you desire, with surgical precision. Cobble up some SQL that automates transformations for a billion records at once. Everything is possible.

Everything is Parallel

Superior spatial data engineering requires parallel power, and parallelism cannot be glued on to non-parallel code. It has to be built-in from the ground up. SQL for ArcGIS Pro was created from the ground up as an always-on, fundamentally parallel system. SQL for ArcGIS Pro always automatically runs parallel

Whenever it makes sense to do so, SQL for ArcGIS Pro will automatically run queries using multiple processor cores and even multiple processors, by parallelizing a query into multiple threads for execution on more than one core. Given hyperthreading plus multi-core CPUs it is now routine to encounter desktop systems with 16, 32, 64 or even more CPU threads available. See the Parallel CPU page for info on CPU parallelism in SQL for ArcGIS Pro.

In addition to parallel processing on many CPU cores, SQL for ArcGIS Pro also includes massively parallel processing with GPUs, potentially launching queries on thousands of processing cores at once. Massively parallel processing on thousands of GPU cores provides supercomputer computational performance for math-intensive queries, far beyond what can be achieved with CPU parallelism.

SQL for ArcGIS Pro automatically parallelizes and dispatches as many tasks as make sense to GPU, with automatic fallback to parallelized tasks dispatched to multiple CPU cores if a GPU is not available. CPU parallelism in SQL for ArcGIS Pro is also a key part of providing massively parallel GPU function, because many CPU cores working in parallel are required to ensure maximum use of GPU. A single CPU core is not fast enough to keep many GPU cores fed with tasks.

Supercomputer Speed with GPU

GPU acceleration works everywhere in SQL for ArcGIS Pro where worthwhile work arises: in the SELECT list, in WHERE, in EXECUTE, ...everywhere. For example, if you add to a table a computed field that combines multiple tiles together, that computed field will use parallel GPU. If you do some tile math in a FUNCTION, that FUNCTION will use parallel GPU as well.

To enjoy parallel speed with SQL you don't have to write something special or learn programming environments like HADOOP or CUDA. Use the same SQL you already know and SQL for ArcGIS Pro automatically parallelizes it to use parallel CPU and GPU. If you don't use SQL but prefer point-and-click templates using Advanced mode in SQL for ArcGIS Pro, those templates automatically use parallel CPU and GPU as well.

When you write something like SELECT tilea + tileb ∗ 5 + tilec ∗ 8 FROM ..., the SQL engine takes the expression with three additions and two multiplications, generates parallel GPU code for that function in a Just In Time (JIT) manner and uploads the resulting code to parallel GPU to execute the computations.

To save execution time and boost efficiency, JIT code generation for parallel GPU functions is cache-friendly for the GPU driver. Running the same query again, or even running different queries for which the parallel GPU expressions are sufficiently similar to each other, will engage the compilation cache maintained by the driver. Saving snippets of SQL to define computed fields or new functions saves the GPU code as well.

If you save the project using that computed field or function into a Manifold .map project file and then open that .map file on a machine running SQL for ArcGIS Pro that has no GPU, the computed field will be executed by SQL for ArcGIS Pro automatically falling back to using CPU parallelism, taking advantage of as many CPU cores are available using CPU parallelism instead of parallel GPU. If you launch that .map file on a machine that has a GPU, SQL for ArcGIS Pro will automatically use the GPU.

Other optimizations play along transparently. If a particular subexpression inside of an expression that runs on parallel GPU is a constant in the context of that expression, it will only be evaluated once. If an expression that can run on parallel GPU refers to data from multiple tables and has parts that only reference one of these tables, the join optimizer will split the parallel GPU expression into pieces according to dependencies and will run these pieces separately and at different times, minimizing work. A SELECT with more than one thread will run multiple copies of parallel GPU expressions simultaneously. There are many other similar optimizations automatically integrated with parallel GPU utilization.

Some operations are so trivial in terms of computational requirements it makes no sense to dispatch them to parallel GPU, the classic case being scalars (trivial) as opposed to tiles (more bulk). CASE expressions, conditionals and similar constructions or functions that operate on scalar values stay on parallel CPU while functions that operate on tile values generally go to parallel GPU unless they use tiles in a trivial fashion, such as making a simple comparison.

SQL for ArcGIS Pro's automatic CPU parallelism with typical multicore CPUs is so fast that keeping lighter operations on parallel CPU is faster than packaging them for dispatch to GPU. Each processor core in a modern CPUs is a very powerful computing machine: When SQL parallelizes a task to twenty four or thirty two CPU hypercores, that is a massive amount of computing power. SQL for ArcGIS Pro automatically adapts to however many CPU cores are in the computer: even inexpensive Threadrippers provide 48 threads, and SQL can exploit every one of them to surge through even the most demanding jobs.


  • Abs(v) takes a number and returns a number: it stays on parallel CPU.
  • TileAbs(t) takes a tile and returns a tile: it can go to parallel GPU.
  • TileContrast(t, c, p) takes a tile and two numbers, and returns a tile: it can go to parallel GPU.
  • TileToValues stays on parallel CPU since it is simply splitting pixels out of a tile with no need for parallel GPU for something so simple. If the operation was doing a computation on the pixels first and then splitting it might then be sent to parallel GPU.

CASE conditions are scalar, so they stay on parallel CPU. When CASE is used with tiles whether it is faster to dispatch the task to parallel GPU depends on exactly how the tiles are used. Following are some examples where vXX are scalar values and tXX are tiles:


In the above not much is being done with the tiles so the entire construction stays on parallel CPU.

CASE v WHEN 3 THEN TileAbs(t1)+ t2*t3 + TileSqrt(t4) ELSE t1 END

In the above, the expression in THEN will go to parallel GPU while the rest of CASE will stay on parallel CPU.


In the above the comparison in WHEN does use tiles but it uses them like raw binary values, similar to how ORDER works, so it is more efficient to leave it on parallel CPU.

GPU card

How Fast Is GPU Parallelism in SQL for ArcGIS Pro?

If you are doing computations it's fast. Really fast. Gains are usually from 20 times faster to 100 times faster than running typical computations on parallel CPU alone, even when using very inexpensive GPU cards. Running complex computations on faster cards, performance can be 100 to 200 times faster than using parallel CPU alone. It's fairly common to do in a second or two what takes Arc more than five minutes without SQL for ArcGIS Pro.

If your time is worth more than minimum wage and you're doing anything that requires your machine to think at a higher level than your coffee pot timer, you'll often pay back the cost of a SQL for ArcGIS Pro license the first time you use it for anything serious. It's that fast.

virtuoso Spatial Functions

Whatever your tool does not provide you get to write yourself, so it's critically important your spatial SQL tool provides everything you need.

SQL for ArcGIS Pro provides every statement, clause, and SQL function you need to blend, transform, analyze and manipulate the world's most complex spatial data in a flash. SQL's sophisticated parallelized spatial operators, like topology and spatial overlays, work with mixed objects, pathological geometry and do not require special data cleaning or simplification before use.

Hundreds of specialized SQL for ArcGIS Pro functions are waiting for you patiently on the shelf, tucked unobtrusively out of the way but bristling with power, ready to hammer data with unstoppable intelligence when your SQL calls them.

Our Place or Yours?

Execute queries that mix and match SQL for ArcGIS Pro functions and SQL with what an external query engine can do: Use Manifold SQL within Oracle or vice versa. SQL for ArcGIS Pro slices queries for dispatch however you want.

"Yes, I shall take credit as being the first living human to ever do this (I feel just like Neil Armstrong, or Rosa Parks). OK, that's a bit of stretch :-) But, think about what we are doing: 1. I've written a SQLite/spatiaLite query (it could have easily been PostGIS, Oracle, SQLServer) [...] 2. I am selecting the result of the SQLite query and combining it with a Manifold spatial function. 3. The result is being selected back into a SQLite table. This is an excellent example of how Manifold really can be a Rosetta Stone to all the different packages out there, in a truly unique way. What other product can pull this off ?" - Forum post

Location, Location, Location

SQL for ArcGIS Pro includes automatic support for over 7500 different coordinate systems and over 1500 coordinate system transformations, including all of EPSG and numerous other spatial reference systems. SQL functions and Transform templates provide full convertability between GeoJSON, WKB, WKT, GML and other systems as well as extensive support for parallelized coordinate system transformations for rasters and vectors.

SQL uses exceptionally high precision coordinate system and base coordinate system transformations including all standard high precision routines used worldwide. You don't have to pay anything extra to get NTv2, HARN, NADCON5, and 170+ grids. Those are all built in and included in the price.

SQL Writes SQL For You

You know those "Hello, World" moments when you really would like to see how it's done in a new system, to learn how to cut through infrastructure and do what you want? SQL for ArcGIS Pro makes that easy for you by automatically writing SQL to show you how it's done.

Want to see how a point-and-click template works? Click the Edit Query button and SQL for ArcGIS Pro launches a command window loaded with the SQL the template executes so you can see how functions are being used. It's a live query, so you can customize the SQL as you like or copy and paste into new queries.

SQL Everywhere

You can use snippets of SQL everywhere in SQL for ArcGIS Pro. When a point-and-click combo box allows you to pick a field you can write an SQL expression into that combo box to customize what the dialog does.

Maybe we want to copy a value into a field from a Date field but instead of copying the Date we want to copy the day of the month, but as a text value. No problem - we write CAST(DateTimeDay([Date]) AS NVARCHAR) into the combo box instead of simply choosing the Date field. We not only get the day of the month, we also CAST it into text form.

Why does this page have a photo of Sainte Chapelle? Because Sainte Chapelle is perfect, the highest and best implementation of Gothic aspirations in architecture. SQL for ArcGIS Pro is like that too - not perfect like Sainte Chapelle, but for spatial work head and shoulders above all else and devoted to honoring the mighty idea that is SQL. Try it and see if you agree.

Buy Now via the Online Store

Buy SQL for ArcGIS® Pro on the Online Store. The store is open 24 hours / seven days a week / every day of the year. Orders are processed immediately with a serial number sent out by email in seconds. Enjoy the world's best desktop spatial SQL today!

 Click to begin shopping

A Sample List

Tired of "spatial" SQL products that provide a handful of functions? That's not SQL for ArcGIS Pro. SQL for ArcGIS Pro has you covered for every possible need with a vast selection of SQL statements, operators and functions. Manifold's spatial experts with decades of experience in spatial engineering have provided everything that everyone from a novice to maximum expert will want, all neatly organized within the query builder with easy filtration to find just the right function for a task. Following is a sample list of some, but not all, of what you get in SQL for ArcGIS Pro.

  • ADD
  • DROP
  • INTO
  • MOD
  • DIV
  • LIKE
  • IN
  • NOT
  • AND
  • OR
  • XOR
  • CAST
  • CASE
  • Avg
  • Corr
  • Count
  • Covar
  • CovarPop
  • First
  • GeomMergeAreas
  • GeomMergeLines
  • GeomMergePoints
  • GeomUnionAreas
  • GeomUnionBoxes
  • JoinAnd
  • JoinBitAnd
  • JoinBitOr
  • JoinBitXor
  • JoinOr
  • JoinXor
  • Last
  • Max
  • Median
  • Min
  • StDev
  • StDevPop
  • StringJoinTokens
  • Sum
  • Var
  • VarPop
  • Abs
  • Acos
  • Acosh
  • Asin
  • Asinh
  • Atan
  • Atan2
  • Atanh
  • BinaryWkbGeom
  • Cbrt
  • Ceil
  • CeilDecs
  • Chr
  • Coalesce
  • Collate
  • Compare
  • ComponentCoordSystem
  • ComponentName
  • ComponentPath
  • ComponentProperty
  • ComponentType
  • CoordConvert
  • CoordConvertPoint
  • CoordConvertPoint3
  • CoordConvertTile
  • CoordConvertTrace
  • CoordConverterIsIdentity
  • CoordConverterIsScaleShift
  • CoordConverterIsXYZ
  • CoordConverterMake
  • CoordConverterSteps
  • CoordDatum
  • CoordDatumDefault
  • CoordDatumEpsg
  • CoordDatumParameters
  • CoordDatums
  • CoordSystem
  • CoordSystemDefault
  • CoordSystemDefaultLatLon
  • CoordSystemEpsg
  • CoordSystemOverride
  • CoordSystemParse
  • CoordSystemParseEpsg
  • CoordSystemParseOverrides
  • CoordSystemParseSrid
  • CoordSystemParseSridSubtype
  • CoordSystems
  • CoordSystemTypeParameters
  • CoordSystemTypes
  • CoordTransform
  • CoordTransformEpsg
  • CoordTransforms
  • CoordTransformTypeParameters
  • CoordTransformTypes
  • CoordUnit
  • CoordUnitByName
  • CoordUnitDefault
  • CoordUnitDefaultLatLon
  • CoordUnitEpsg
  • CoordUnits
  • Cos
  • Cosh
  • DataLength
  • DateTimeDay
  • DateTimeHour
  • DateTimeMillisecond
  • DateTimeMinute
  • DateTimeMonth
  • DateTimeSecond
  • DateTimeYear
  • Erf
  • Erfc
  • Exp
  • Exp10
  • Exp2
  • Expm1
  • Floor
  • FloorDecs
  • Fract
  • FractDecs
  • GeocodeAddress
  • GeocodeAddressMatches
  • GeocodeAddressSupported
  • GeocodeLocationMatches
  • GeocodeLocationSupported
  • GeomAdjacent
  • GeomArea
  • GeomBounds
  • GeomBox
  • GeomBranch
  • GeomBranchCount
  • GeomBranchFirst
  • GeomBranchLast
  • GeomBuffer
  • GeomCenter
  • GeomCenterInner
  • GeomCenterWeight
  • GeomClip
  • GeomContains
  • GeomConvertToArea
  • GeomConvertToLine
  • GeomConvertToPoint
  • GeomConvexHull
  • GeomCoordCount
  • GeomCoordXY
  • GeomCoordXYZ
  • GeomDistance
  • GeomDistancePoint
  • GeomDistancePoint3
  • GeomGml
  • GeomHasCurves
  • GeomHasZ
  • GeomIntersects
  • GeomIsArea
  • GeomIsLine
  • GeomIsNormalized
  • GeomIsPoint
  • GeomJsonGeo
  • GeomLength
  • GeomLinearize
  • GeomMakeCircle
  • GeomMakePoint
  • GeomMakePoint3
  • GeomMakeRect
  • GeomMakeRectDiagonal
  • GeomMakeSegment
  • GeomMakeSegment3
  • GeomMakeTriangle
  • GeomMakeTriangle3
  • GeomMergeAreasPair
  • GeomMergeLinesPair
  • GeomMergePointsPair
  • GeomNormalize
  • GeomNormalizeTopology
  • GeomOrtho
  • GeomOverlayAdjacent
  • GeomOverlayContained
  • GeomOverlayContaining
  • GeomOverlayIntersecting
  • GeomOverlayTopologyIdentity
  • GeomOverlayTopologyIntersect
  • GeomOverlayTopologyUnion
  • GeomOverlayTopologyUpdate
  • GeomOverlayTouching
  • GeomRemoveCurves
  • GeomRemoveZ
  • GeomRotate
  • GeomScaleShift
  • GeomScaleShiftZ
  • GeomScaleToSystem
  • GeomScaleToSystemCff
  • GeomScaleToUnits
  • GeomScaleToUnitsCff
  • GeomSegmentize
  • GeomSetZ
  • GeomSmooth
  • GeomToBranches
  • GeomToCoords
  • GeomToSegments
  • GeomToShapes
  • GeomToShapesEsri
  • GeomTouches
  • GeomTriangulate
  • GeomTriangulateLines
  • GeomType
  • GeomUnionAreasPair
  • GeomUnionBoxesPair
  • GeomVoronoi
  • GeomVoronoiLines
  • GeomVoronoiPoints
  • GeomWithin
  • GeomWkb
  • GeomWkt
  • Hypot
  • J0
  • J1
  • Jn
  • Lgamma
  • Log
  • Log10
  • Log1p
  • Log2
  • NullIf
  • PragmaValue
  • Rcbrt
  • Round
  • RoundDecs
  • Rsqrt
  • Selection
  • SelectionForWindow
  • SelectionIsEmpty
  • SelectionIsInverted
  • SelectionKeys
  • Sign
  • Sin
  • Sinh
  • Sqrt
  • StringCompareCollate
  • StringCompareKeyCollate
  • StringContains
  • StringContainsCollate
  • StringEndsWith
  • StringEndsWithCollate
  • StringEscape
  • StringEscapeEncode
  • StringEscapeJson
  • StringFind
  • StringFindCollate
  • StringFindNth
  • StringFindNthCollate
  • StringGmlCoordSystem
  • StringGmlGeom
  • StringJsonArray
  • StringJsonBoolean
  • StringJsonGeoCoordSystem
  • StringJsonGeoGeom
  • StringJsonNumber
  • StringJsonObject
  • StringJsonValue
  • StringLength
  • StringPadEnd
  • StringPadStart
  • StringRegexpCount
  • StringRegexpFind
  • StringRegexpFindNth
  • StringRegexpMatches
  • StringRegexpReplace
  • StringRegexpReplaceNth
  • StringRegexpSubstring
  • StringRegexpSubstringNth
  • StringReplace
  • StringReplaceCollate
  • StringReplaceNth
  • StringReplaceNthCollate
  • StringReverse
  • StringSoundex
  • StringStartsWith
  • StringStartsWithCollate
  • StringSubstring
  • StringSubstringLen
  • StringToCharacters
  • StringToJsonArrayValues
  • StringToJsonObjectValues
  • StringToLowerCase
  • StringToLowerCaseCollate
  • StringToRegexpMatches
  • StringToTitleCase
  • StringToTitleCaseCollate
  • StringToTokens
  • StringToUpperCase
  • StringToUpperCaseCollate
  • StringTranslate
  • StringTrim
  • StringTrimEnd
  • StringTrimStart
  • StringUnescape
  • StringUnescapeDecode
  • StringUnescapeJson
  • StringWktGeom
  • SystemCpuCount
  • SystemGpgpuCount
  • SystemGpgpus
  • Tan
  • Tanh
  • Tgamma
  • TileAbs
  • TileAcos
  • TileAcosh
  • TileAsin
  • TileAspect
  • TileAtan
  • TileAtan2
  • TileAtanh
  • TileBgrHcy
  • TileBgrHsi
  • TileBgrHsl
  • TileBgrHsv
  • TileBlur
  • TileBlurDirection
  • TileBlurGaussian
  • TileCbrt
  • TileCeil
  • TileChannel
  • TileChannelCount
  • TileChannels
  • TileChannelsConcat
  • TileCombine
  • TileCompare
  • TileContrast
  • TileCos
  • TileCosh
  • TileCut
  • TileCutBorder
  • TileCutRect
  • TileEdges
  • TileEdgesDirection
  • TileErf
  • TileErfc
  • TileExp
  • TileExp10
  • TileExp2
  • TileExpm1
  • TileFill
  • TileFloor
  • TileFloorDecs
  • TileFract
  • TileFractDecs
  • TileHcyBgr
  • TileHsiBgr
  • TileHslBgr
  • TileHsvBgr
  • TileHypot
  • TileJ0
  • TileJ1
  • TileJn
  • TileLgamma
  • TileLog
  • TileLog10
  • TileLog1p
  • TileLog2
  • TileMakeNew
  • TileMaskExtract
  • TileMaskReplace
  • TileMax
  • TileMin
  • TileNoise
  • TileRcbrt
  • TileRound
  • TileRoundDecs
  • TileRsqrt
  • TileSharpen
  • TileSign
  • TileSin
  • TileSinh
  • TileSlope
  • TileSqrt
  • TileTan
  • TileTanh
  • TileTgamma
  • TileToValues
  • TileToValuesX2
  • TileToValuesX3
  • TileToValuesX4
  • TileTrunc
  • TileTruncDecs
  • TileUpdatePyramids
  • TileY0
  • TileY1
  • TileYn
  • Trunc
  • TruncDecs
  • UuidMakeNew
  • ValueCount
  • ValueMax
  • ValueMin
  • ValueSequence
  • VectorBgrHcy
  • VectorBgrHsi
  • VectorBgrHsl
  • VectorBgrHsv
  • VectorHcyBgr
  • VectorHsiBgr
  • VectorHslBgr
  • VectorHsvBgr
  • VectorMakeX2
  • VectorMakeX3
  • VectorMakeX4
  • VectorValue
  • VectorValues
  • Y0
  • Y1
  • Yn

SQL for ArcGIS Pro imports everything.

SQL for ArcGIS Pro imports everything: SQL for ArcGIS Pro works with hundreds of different data sources, including almost any file format, database, or web protocol imaginable. The image shows parcel data in Australia imported from a MapInfo TAB format file.

About Manifold

Manifold is a deep technology company creating advanced, parallel algorithms, next-level technology, and computation know-how that powers faster performance and smarter operations.

License Manifold® technology to power your company's products, or take advantage of Manifold's off-the-shelf commercial products. Jump decades ahead of your competition.

Manifold® products deliver quality, performance and value in the world's most sophisticated, most modern, and most powerful spatial products for GIS, ETL, DBMS, and Data Science. Total integration ensures ease of use, amazing speed, and unbeatably low cost of ownership. Tell your friends!

Questions? Contact We're happy to help!