37° 48' 15.7068'' N, 122° 16' 15.9996'' W
cloud-native gis has arrived
37° 48' 15.7068'' N, 122° 16' 15.9996'' W
cloud-native gis has arrived
37° 48' 15.7068'' N, 122° 16' 15.9996'' W
cloud-native gis has arrived
37° 48' 15.7068'' N, 122° 16' 15.9996'' W
cloud-native gis has arrived
37° 48' 15.7068'' N, 122° 16' 15.9996'' W
cloud-native gis has arrived
37° 48' 15.7068'' N, 122° 16' 15.9996'' W
cloud-native gis has arrived
37° 48' 15.7068'' N, 122° 16' 15.9996'' W
cloud-native gis has arrived
37° 48' 15.7068'' N, 122° 16' 15.9996'' W
cloud-native gis has arrived
37° 48' 15.7068'' N, 122° 16' 15.9996'' W
cloud-native gis has arrived
37° 48' 15.7068'' N, 122° 16' 15.9996'' W
cloud-native gis has arrived
Ask a question. Get a map. The new era of GIS, powered by Felt AI. Learn more
Maps
BLOG
Product
Query your warehouse directly: live maps without ETL or Python
Snowflake, BigQuery, and Databricks, queried with spatial SQL or natural language, refreshed on your own schedule.
Snowflake, BigQuery, and Databricks, queried with spatial SQL or natural language, refreshed on your own schedule.

Your best spatial data already lives in a data warehouse. The challenge is getting it into a map, fast.

A map built on last night's export is not wrong. It is just describing a world that has already moved on.

Today it usually looks like this. A scheduled job extracts the data from Snowflake or BigQuery overnight, transforms it, and loads a copy into a separate mapping tool. That transform step is rarely as light as it sounds. Someone still has to clean and reshape the data by hand before it is fit to load. All of that happens before anyone opens the map, and the map is already behind by the time they do.

This gap between the warehouse and the map has two costs. The first is staleness. Every copy is a chance for the data to move further away from the source, and every transform is one more thing that breaks when a column gets renamed upstream. The second cost is quieter but more expensive. That journey from warehouse to map requires SQL and scripting, which means it requires someone who knows SQL and scripting. Everyone else files a request and waits. The person who knows the question is rarely the person allowed to ask it.

When the warehouse becomes the map's source of truth

For most of the history of GIS, spatial data lived in a store of its own: a shapefile, a geodatabase, something the GIS team stood up and kept in sync separately from the map. What is changing is that the cloud warehouse your company already runs on can be the source the map reads from directly, instead of a copy built just for the map.

Querying the warehouse directly is not a feature bolted onto the map. It is the interface. When the map reads from the same tables two different teams already report from, it never tells a different story than they do. There is one version of the data, and everyone sees it through the tool that fits their question.

That's the shift Felt is built around.

What Felt is

Felt is an AI-native GIS platform that lets any team, not only GIS specialists, go from a spatial question to a live, interactive map or app connected to the data you already run. It connects directly to Snowflake, BigQuery, Databricks, Redshift, and Postgres/PostGIS, along with S3, Azure, Google Cloud, and Esri feature services.

Felt connects through a read-only database user and keeps its queries against your warehouse to a minimum, which makes access straightforward for an IT team to audit. Enterprise controls like SSO and role-based access sit on top. Felt does build vector tiles from your data to keep the map fast to render, but it does not ask your team to move, manage, or reconcile copies of files themselves, and it does not create a second source of truth. The warehouse stays authoritative. The map is a live view onto it.

This is why data teams are looking to cloud-native, AI-native GIS right now. The hard part was never drawing the map. It was keeping the map honest against a system of record that never stops changing. Reading directly from the warehouse is how you do it.

Two ways to query your data warehouse in Felt

Some people want an answer without learning a query language. Others want their hands on the SQL. You can do both with Felt.

Keep your hands on the SQL

Connect your warehouse to Felt as a live source and it appears as a catalog of your tables and views. Setup is deliberately straightforward: create a read-only database user, then in Data sources add a new source, choose your warehouse, enter credentials, and connect.

From there, Felt's SQL editor runs spatial SQL directly against the live connection: filter to the geometries you need, join what needs joining, and turn it into a map layer. Don't want to start from a blank editor? Describe what you're after and Felt AI drafts the SQL right there for you to inspect, edit, and run. Either way the query is yours to read and change, and it only ever runs as a read-only SELECT against your database. Felt reads live from the source, so there is no second copy to maintain and none of the file-size limits you hit uploading through a browser. Layers built this way refresh on the cadence you set, so you decide how current the map stays. You stay in full control here.

Or just ask: conversational querying with Felt AI assistant

Sometimes you just want the answer, not the query. Open the Felt AI assistant on your map and ask the way you'd ask a colleague. Show me stores in the top quartile of revenue within two miles of a competitor. Show me distribution poles rated in poor condition inside high fire-risk zones that haven't been inspected in the last twelve months. The assistant writes and runs the SQL against your Snowflake, BigQuery, or Databricks tables, turns the results into a layer, and narrates each step as it goes. No query editor, no Python, no ticket, no wait. The SQL runs behind the scenes while you keep talking to your map in plain language, and what comes back is real spatial analysis, mapped and ready to share.

See it on your own data

Your warehouse already has the answer. Now your map can show it. The fastest way to see that is to watch your own data do it. Connect with our team to see how you can build a live map on your data.

FAQ

Can I map BigQuery data without writing Python?

Yes. Connect BigQuery to Felt as a live source and its tables appear as a catalog you can map directly. Write spatial SQL if you want fine control, or ask Felt AI a natural language question and let it write the query. Neither path requires Python or an export script.

Does connecting Snowflake to Felt require ETL?

No. Felt reads from Snowflake through a live connection rather than an extract-transform-load pipeline. You connect with a read-only user, your tables and views appear as mappable layers, and they refresh on the cadence you choose. There is no separate copy to build or maintain.

Which data warehouses and databases does Felt connect to?

Felt connects directly to Amazon Redshift, Amazon S3 buckets, Microsoft Azure blob storage, Google BigQuery, Databricks, Esri ArcGIS image, map and feature services, Google Cloud Storage, Microsoft SQL Server, PostgreSQL / PostGIS, Snowflake, STAC catalogs, Web Feature Server (WFS), Web Mapping Service (WMS / WMTS), and Wherobots.

Do I need to know SQL to analyze warehouse data in Felt?

No. Write spatial SQL yourself against the live connection, or ask Felt AI assistant in natural language and skip the SQL entirely.

How does Felt keep warehouse data current on the map?

Layers built from a live connection refresh on the cadence you set. Query directly, through the SQL editor or by asking Felt AI assistant, and you get the answer from the source at that moment.

Bio
LinkedIn
Start creating maps, apps, and dashboards today
Try Felt for Free
More articles

April spotlight: 10 best Felt Community maps

Felt’s public beta, and a new $15M round of funding

4 Best practices to conduct a real estate investment analysis