Snowflake Hybrid Tables and Unistore in Practice

Q: Can I join a hybrid table to a regular Snowflake table?

Yes. A single SELECT can read from any mix of hybrid and FDN tables. The planner pushes the hybrid-side work through the transactional engine's index access and runs the join in the standard warehouse. This is the killer feature of hybrid tables for analytical workloads that need to combine current state with historical depth.

Q: Can I create indexes on a hybrid table after it has been loaded?

Yes. CREATE INDEX idx_name ON hybrid_table (col1, col2) works on populated tables. The index is built online without taking the table offline, though large tables take time and consume compute during the build.

How Snowflake hybrid tables (Unistore) actually work: row-based storage, enforced primary keys, secondary indexes, hybrid-FDN joins, and the workloads where they pay off.

This post was written by an engineer at QueryPlane. QueryPlane is an app builder for your database: bring your own postgres db and you can create interactive applications to share with other developers, coworkers or even your customers. If you’re interested in trying it out, get started here.

Snowflake was built as an analytical warehouse. Columnar storage, micro-partitions, scan-heavy queries — every architectural decision favors batch reads of large tables. That model breaks down when an application needs to read a single row by primary key in 10 milliseconds, update it without rewriting a micro-partition, and have the change visible to the next reader immediately. Until hybrid tables shipped under the Unistore initiative, the answer was “use a separate operational database and copy the data over.” That answer leaves a seam, and seams cost engineering time.

Hybrid tables remove the seam. They are first-class Snowflake objects, queryable in the same SQL, joinable to standard tables, governed by the same RBAC — but stored row-wise in a transactional engine that supports enforced primary keys, secondary indexes, foreign-key constraints, and millisecond-latency point reads. This post is a practical guide to using them in production: what they are, when they pay off, how to design schemas, what the cost model looks like, and which features the documentation still warns against.

In this post, we’ll cover:

What hybrid tables are — row-based storage, the Unistore architecture, how they sit alongside FDN tables
When to use them — the workloads they fit and the ones that should stay in your OLTP database
Schema design — primary keys, secondary indexes, foreign keys, and the constraint enforcement that standard tables lack
Hybrid + FDN joins — the headline feature, with the planner behavior that makes it work
Performance characteristics — point lookups, range scans, update throughput, and what to measure
Cost model — storage rate, serverless compute, and where the bill actually lands
Limitations — feature gaps, account-level requirements, region restrictions
Operational details — replication, time travel, backups, change tracking
Common patterns — feature flags, application metadata, real-time aggregates over hot keys
Pitfalls — the recurring mistakes from production rollouts

What hybrid tables are

A standard Snowflake table — what the docs now call an FDN (File Data Native) table — stores its data in compressed columnar files inside cloud object storage. Reads are bulk-oriented: even a WHERE id = 12345 query reads the whole micro-partition that contains row 12345, decompressing the column data and filtering down. Writes append new micro-partitions, with updates and deletes implemented as tombstones plus rewrites at merge time. That model is efficient for “scan a billion rows, group by hour, return ten buckets,” and inefficient for “fetch one row by id.”

A hybrid table is the same logical SQL object — same CREATE TABLE grammar with a different keyword, same INSERT / SELECT / UPDATE / DELETE operations, same RBAC, same warehouses — but the underlying storage is a row-oriented transactional engine. Snowflake has not named the engine publicly in its docs, but it is broadly understood to be derived from FoundationDB, the ordered key-value store Apple open-sourced in 2018. The engine sits inside the Snowflake cloud services layer rather than in object storage, replicated synchronously across availability zones, and serves point lookups in single-digit milliseconds.

The user-visible consequences are:

Enforced constraints. PRIMARY KEY, UNIQUE, and FOREIGN KEY are enforced at write time on hybrid tables. On standard tables those clauses are metadata only — Snowflake records them but does not check them. A hybrid table will reject duplicate primary keys and reject inserts that violate a foreign key reference.
Secondary indexes. You can CREATE INDEX idx_name ON hybrid_table (col1, col2) and queries with predicates on those columns use the index for point and range lookups. Standard tables have no secondary indexes; the only access path is micro-partition pruning.
Single-row read latency. A primary-key lookup returns in low single-digit milliseconds rather than the multi-hundred-millisecond floor of FDN table queries.
Single-row write latency. An INSERT of one row commits in similar latency, with full ACID semantics including read-your-writes within the same transaction.
Mixed-engine joins. A query can join a hybrid table to one or more FDN tables in the same SELECT, and the planner pushes the right work to each side.

The Unistore vision

Unistore is the marketing term for the larger initiative: support transactional workloads inside Snowflake, alongside analytical workloads, so that operational data and analytical data live in the same governance perimeter and the same query surface. Hybrid tables are the first concrete Unistore feature; future Unistore work includes deeper application-tier integration, more transactional primitives, and tighter performance optimization for mixed workloads.

The practical promise is that a team running both a transactional system and an analytical warehouse no longer needs change data capture, no longer needs to keep two RBAC models in sync, and no longer needs to maintain a separate ops database for every workload that has both transactional and analytical reads. The promise is real for a narrow but valuable slice of workloads. It is not real for “replace your application’s Postgres database” — Snowflake is not pricing or positioning hybrid tables that way.

When hybrid tables are the right answer

The question to ask before reaching for a hybrid table is: what specifically about this workload is wrong on a standard Snowflake table? If the answer is “nothing — I just need analytics,” use an FDN table. If the answer is one of the following, hybrid tables are worth evaluating.

You need millisecond point reads on a small number of rows. A dashboard that looks up the current value of a metric for a specific customer, a user-facing feature flag service backed by Snowflake, a real-time configuration store — these read patterns are slow on FDN tables and fast on hybrid tables.

You need enforced uniqueness or referential integrity. Standard Snowflake tables let invalid data in. If your workflow depends on PRIMARY KEY actually rejecting duplicates — for example, an idempotency-key table where a duplicate insert must fail loudly — hybrid tables enforce that for free. The workaround on FDN tables is a MERGE with explicit check logic, which is more code and weaker semantics.

You need to update individual rows frequently. An order-status table updated as the order moves through fulfillment, an inventory table decremented on each sale, a session table updated on each user action — high-volume row-level updates churn micro-partitions on FDN tables and pay automatic-clustering credits to keep up. Hybrid tables update in place.

You need to join transactional state to analytical history in one query. This is the headline. A query that joins a hybrid table of current customer attributes to a 5-TB FDN table of historical orders runs in one SQL statement against one engine. With separate Postgres and Snowflake databases, the same query requires CDC plumbing or an out-of-band federated query layer.

The wrong reasons to reach for a hybrid table:

“Snowflake is our database.” If you have an actual transactional application — high request rate, latency-critical, complex transaction graphs — a purpose-built OLTP database is cheaper, faster, and better understood. Hybrid tables are not pricing-competitive with Postgres or Aurora for that use case. Snowflake’s pricing model is per-compute-second; an OLTP database is per-instance-month.
“We want to avoid CDC.” CDC is annoying, but it is well-understood and well-tooled. If your only motivation is avoiding pipeline plumbing, the math may not work — hybrid table storage and per-operation costs are higher than equivalent FDN table costs.
“We need ACID transactions.” Standard Snowflake tables also support multi-statement ACID transactions. ACID is not the differentiator; the differentiator is single-row latency and enforced constraints.

Schema design

The CREATE HYBRID TABLE syntax is almost identical to CREATE TABLE, with two material differences: every hybrid table requires a primary key, and indexes and foreign keys are declared inline.

CREATE HYBRID TABLE customers (
  customer_id      NUMBER       NOT NULL PRIMARY KEY,
  email            VARCHAR(254) NOT NULL,
  tier             VARCHAR(20)  NOT NULL DEFAULT 'free',
  created_at       TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP(),

  UNIQUE (email),
  INDEX idx_tier (tier)
);

Three things to notice:

PRIMARY KEY is mandatory. Every hybrid table needs one. The primary key is the physical organization of the data — rows are stored sorted by primary key in the underlying engine. Choose a primary key that matches your dominant access pattern. For a customers table, customer_id is the obvious choice. For an events table, a composite (customer_id, event_ts) is usually better than a synthetic event_id because it co-locates a customer’s events for range scans.

UNIQUE is a secondary index plus a constraint. Declaring UNIQUE (email) both creates a secondary index on email and rejects duplicate inserts. On FDN tables, UNIQUE is metadata only — no index, no enforcement.

INDEX clauses are inline. Unlike Postgres, where indexes are created with separate CREATE INDEX statements, hybrid tables prefer inline index declarations on CREATE. You can still add indexes later with CREATE INDEX, but inline is the cleaner form when you know the access pattern up front.

Foreign keys are also enforced:

CREATE HYBRID TABLE orders (
  order_id      NUMBER       NOT NULL PRIMARY KEY,
  customer_id   NUMBER       NOT NULL,
  status        VARCHAR(20)  NOT NULL DEFAULT 'pending',
  total_cents   NUMBER       NOT NULL,
  created_at    TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP(),

  INDEX idx_customer_created (customer_id, created_at),
  INDEX idx_status (status),

  FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

An INSERT INTO orders with a customer_id that does not exist in customers will be rejected by the engine. A DELETE FROM customers for a row referenced by orders will be rejected unless you have configured ON DELETE CASCADE (supported). This is real database behavior, not the metadata-only constraints of FDN tables.

A composite-key example — useful when the natural access pattern is “all rows for this entity in this time range”:

CREATE HYBRID TABLE user_events (
  user_id     NUMBER         NOT NULL,
  event_ts    TIMESTAMP_NTZ  NOT NULL,
  event_type  VARCHAR(40)    NOT NULL,
  payload     VARIANT,

  PRIMARY KEY (user_id, event_ts),
  INDEX idx_type_ts (event_type, event_ts)
);

Rows are sorted by (user_id, event_ts) on disk. A query for WHERE user_id = 42 AND event_ts >= ... does a single contiguous range read. A query for WHERE event_type = 'signup' AND event_ts >= ... uses the secondary index. A query for WHERE event_ts >= ... alone — no leading user_id — falls back to a full scan, just as it would in Postgres.

Index column ordering matters for the same reasons it matters in any B-tree-backed system. Put the column that always appears in equality predicates first, the column that appears in range predicates second.

See what QueryPlane can build for you

Connect to your database, write SQL with AI, and build shareable apps — all from your browser.

Get Started Book a Demo

Joining hybrid tables to FDN tables

This is the killer feature. A single query can read from one or more hybrid tables and one or more FDN tables, and the planner handles the join.

SELECT
  c.tier,
  COUNT(*)                AS orders_30d,
  SUM(o.total_cents) / 100 AS revenue_30d,
  AVG(h.lifetime_value)    AS avg_ltv
FROM orders o                              -- hybrid, current state
JOIN customers c   ON c.customer_id = o.customer_id   -- hybrid
JOIN customer_history h ON h.customer_id = o.customer_id -- FDN, historical
WHERE o.created_at >= DATEADD(day, -30, CURRENT_DATE())
  AND o.status = 'paid'
GROUP BY c.tier;

The planner reads the hybrid side using index access — orders filters on created_at and status, both of which can use the inline indexes — and the FDN side using its normal partition-pruning machinery. The hybrid table’s rows are streamed to the warehouse where the join executes. This is fast for small to medium hybrid result sets and slower for joins that have to pull millions of rows out of the hybrid engine.

A practical rule of thumb: hybrid tables work best as the dimension side of a star schema or the current-state side of a current-state-vs-history join. If your query is reading a million rows from the hybrid table to join against 10,000 rows from the FDN table, you have the join shape backwards. Either restructure the query to push predicates onto the hybrid side first, or move the data into an FDN table.

The same warehouse that runs your analytical queries runs the join — there is no separate “hybrid warehouse” concept. Sizing is the standard Snowflake warehouse sizing decision; an XSMALL handles most hybrid-side workloads because the heavy lifting is done index-side in the underlying engine, not in the warehouse.

Performance characteristics

Three numbers govern how a hybrid table performs in production: primary-key lookup latency, secondary-index lookup latency, and bulk-scan throughput.

Primary-key lookups are the strongest performance story. A SELECT * FROM orders WHERE order_id = 9001 against a hybrid table returns in roughly 5-15 ms end-to-end at low concurrency, depending on region, replication topology, and warehouse warm state. This is the workload hybrid tables were designed for.

Secondary-index lookups are slightly slower than primary-key lookups but still in the low-tens-of-milliseconds range. A query whose predicate fully matches a secondary index — WHERE customer_id = 42 AND status = 'paid' against INDEX (customer_id, status) — fetches the matching rows from the index directly. A query whose predicate only partially matches falls back to scanning the index then filtering, which is slower but still much faster than an FDN equivalent.

Bulk scans are slower on hybrid tables than on FDN tables for the same logical data. Columnar storage is built for scanning; row storage is built for point access. If your workload is “read 100 million rows and aggregate,” hybrid tables are the wrong choice — that is what FDN tables are for. A useful mental model: hybrid tables beat FDN tables up to about a 10,000-row result set and start losing above that.

To measure your own workload, the relevant views are:

-- per-query stats including which access path was used
SELECT
  query_text,
  execution_time,
  bytes_scanned,
  rows_produced,
  warehouse_size
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE query_text ILIKE '%FROM orders%'
  AND start_time >= DATEADD(hour, -1, CURRENT_TIMESTAMP())
ORDER BY start_time DESC
LIMIT 50;

For deeper diagnostics, the query profile shows whether a hybrid lookup used an index or a full scan. If you see “FullScan” on a node touching a hybrid table that you expect to hit an index, the index either does not exist for the predicate columns or the optimizer chose not to use it — both fixable.

Cost model

Hybrid table cost has three components: storage, request, and compute.

Storage for hybrid tables is billed at a higher rate per terabyte than standard cloud storage because the data lives in the replicated transactional engine, not in S3 or equivalent object storage. The rate is published in the Snowflake pricing page and varies by region; it is typically several times the standard table rate. For a hybrid table with a few hundred gigabytes of hot operational data, this is negligible; for a hybrid table with multi-terabyte data, it is the dominant line item.

Requests — reads and writes against hybrid tables — are billed serverlessly, separate from warehouse compute. Each operation incurs a small per-request charge. This is the model that distinguishes hybrid table cost from FDN table cost: an FDN query is billed by warehouse seconds, while a hybrid query is billed partly by request count and partly by warehouse time. For high-concurrency point-read workloads, the request charge can dominate.

Compute runs on the standard warehouse pool. A SELECT that hits the hybrid engine and then aggregates on the warehouse pays warehouse credits for the aggregation step. A SELECT that is a pure primary-key lookup may not require warehouse compute at all, depending on the result shape.

The practical implication is that hybrid table pricing optimizes for hot small workloads and penalizes large cold workloads. A 50-GB operational table getting 10 million point reads a day is well-priced. A 5-TB analytical table getting one daily scan is mispriced — that data belongs in an FDN table.

To monitor cost, the views to watch are HYBRID_TABLE_USAGE_HISTORY for account-level hybrid table credit consumption and WAREHOUSE_METERING_HISTORY for the warehouse-side compute. For per-table query activity, use QUERY_HISTORY filtered to the table name. Set up a resource monitor and a weekly review for the first month after rolling out any new hybrid table.

-- account-level hybrid table credit usage in the last 7 days
-- (HYBRID_TABLE_USAGE_HISTORY is account-scoped; per-table breakdown
--  is available in QUERY_HISTORY filtered to hybrid table queries)
SELECT
  DATE_TRUNC('day', start_time) AS day,
  SUM(credits_used)             AS credits_used
FROM SNOWFLAKE.ACCOUNT_USAGE.HYBRID_TABLE_USAGE_HISTORY
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
GROUP BY 1
ORDER BY 1 DESC;

Limitations to know going in

Hybrid tables are in a different feature-maturity tier than FDN tables. Several capabilities you might expect from a Snowflake object are unavailable, restricted, or only partially supported. The current documentation is the authoritative source, but the recurring gaps that catch teams are:

Region availability is partial. Hybrid tables are available in a subset of AWS, Azure, and GCP regions. Before designing around them, confirm your account’s region is on the list — the support matrix changes, and migration after the fact is non-trivial.
Account edition requirement. Hybrid tables require Enterprise Edition or higher.
No fail-safe; limited time travel. Standard tables have up to 90 days of time travel plus 7 days of fail-safe. Hybrid tables support a limited time-travel window (typically up to 1 day, with the actual limit depending on edition) and no fail-safe period. Backup strategy is different — point-in-time restoration is shorter and accidental drops are less recoverable.
No clustering keys. Clustering keys are an FDN-table concept. The primary key serves the same physical-organization role on a hybrid table.
No external table sharing semantics. A hybrid table cannot be shared via secure data sharing the way an FDN table can. If consumers in other accounts need access, the data has to be copied or modeled differently.
Some data types unsupported. GEOGRAPHY, GEOMETRY, and certain semi-structured nesting patterns are not supported on hybrid tables. Confirm your column types are on the supported list before designing the schema.
No copy-on-write cloning of hybrid tables. Zero-copy cloning of an FDN table is instant and free. Cloning a hybrid table is a real copy operation, and it is billed accordingly.
Foreign keys must reference other hybrid tables. A hybrid table cannot have a foreign key into an FDN table. The constraint mechanism does not span engines.
Bulk-load methods differ. COPY INTO and other bulk-load paths work differently for hybrid tables. For an initial load of historical data, expect to use INSERT ... SELECT from a staging FDN table.

The right time to scan the limitations list is before you commit a hybrid table to a workload, not after. A two-week proof-of-concept that hits one of these limitations late costs more than the half-hour of doc reading would have.

Operational details

Replication. Hybrid tables replicate synchronously across the availability zones in their region — this is built into the underlying engine and is not an opt-in. Cross-region replication of hybrid tables is more limited than for FDN tables; check the current docs for your specific compliance requirement.

Time travel. As noted above, time travel on hybrid tables is shorter. Within the supported window, the syntax is the same: SELECT * FROM orders AT(OFFSET => -300) to read the table state five minutes ago.

Streams. Snowflake streams work on hybrid tables. A stream over a hybrid table captures inserts, updates, and deletes and exposes them to downstream MERGE statements, which is the foundation for keeping a derived FDN table in sync with a hybrid source.

Change tracking. Hybrid tables support CHANGE_TRACKING = TRUE, the same metadata flag used by streams. Enable it if you plan to read change data via CHANGES (INFORMATION => DEFAULT) clauses or downstream streams.

Backups. With no fail-safe, accidental drops are unrecoverable past the time-travel window. Treat hybrid tables the way you would treat any production OLTP database: schema-as-code in version control, periodic schema dumps to FDN tables, and a tested recovery procedure that does not rely on Snowflake support being able to “find the data” days later.

Common patterns

A few patterns recur across teams that have moved workloads to hybrid tables.

Feature flags and configuration. A flags table with (flag_name, env, value, updated_at, updated_by) as columns and (flag_name, env) as the primary key. Application code reads SELECT value FROM feature_flags WHERE flag_name = ? AND env = ? on every request hot path. Writes are rare; reads are very frequent. The point-read latency profile is exactly what hybrid tables were built for, and the same data is queryable from analytical jobs to correlate flag changes with metrics.

Idempotency keys. A table that stores (request_id, response_hash, expires_at) to dedupe API requests. The application inserts request_id and depends on the primary-key uniqueness violation to detect a replay. FDN tables cannot enforce this; hybrid tables do it natively.

Real-time aggregates over a small hot set. A current-totals table updated on each user action — current cart total, current points balance, current month-to-date spend. Each event is one row update, replacing the previous total. Reads are per-user point lookups. This pattern is unworkable on FDN tables (every update tombstones a partition) and natural on hybrid tables.

Application metadata that needs analytics co-location. A multi-tenant SaaS app’s tenants, users, subscriptions, and entitlements tables that need to be joined against event history in the warehouse. Putting these in hybrid tables means the operational reads stay fast and the analytical joins do not need CDC.

Lookup tables for streaming pipelines. A stream-and-task pipeline that needs to enrich incoming events with the current state of a small reference table. Reading the reference table from a hybrid table on each task run is fast and keeps the pipeline self-contained inside Snowflake.

Pitfalls

The recurring mistakes from production rollouts:

Treating hybrid tables as a Postgres replacement. They are not. They cost more per row and per request than a dedicated OLTP database, and the feature set — triggers, stored procedures with complex transaction logic, extensions — is narrower. If your only requirement is OLTP and your team already runs Postgres or MySQL, those are the better answer.

Indexing too liberally. Every secondary index costs storage and slows down writes. The Postgres habit of adding an index on every column “just in case” wastes hybrid-table money. Add indexes that match the actual query predicates and stop.

Picking the wrong primary key. A monotonically increasing primary key (a sequence, a timestamp, a UUIDv7) co-locates recent rows, which is good for time-range scans and bad for write hot-spotting at very high write concurrency. A fully random primary key (UUIDv4) spreads writes across the keyspace, which is good for write distribution and bad for range scans. The right answer depends on your workload, and you should think about it for an hour before committing.

Loading multi-terabyte history into a hybrid table. The first instinct of teams new to hybrid tables is to migrate everything. Resist it. Hybrid tables are for hot operational data — the last 30 days, the current customer set, the active orders. Historical data belongs in FDN tables, with the hybrid-to-FDN join handling the seam in queries.

Skipping the limitations review. Several teams have built around a hybrid table for two weeks and then discovered the type they need is unsupported, or the region is unavailable, or the data-sharing requirement cannot be met. Read the official limitations doc on day one.

Forgetting that constraint violations now happen. With FDN tables, an INSERT with a duplicate primary key silently succeeds and leaves duplicate rows. With hybrid tables, the same insert raises an error. Application code that was tolerant of duplicates needs to handle the rejection — usually with INSERT IF NOT EXISTS or MERGE patterns.

Not monitoring request volume. A point-read workload that grows from 100k to 100M requests per day quietly multiplies the credit bill. The HYBRID_TABLE_USAGE_HISTORY view tracks account-level credit consumption; pair it with QUERY_HISTORY to understand which tables are driving volume. Set up alerts before the first production rollout, not after the first invoice.

Frequently asked questions

Are Snowflake hybrid tables the same as Unistore? Hybrid tables are the first user-facing feature of Snowflake’s Unistore initiative. Unistore is the broader strategy of supporting transactional workloads inside Snowflake; hybrid tables are the implementation piece you actually interact with today.

What is the difference between a hybrid table and a standard Snowflake table? Standard (FDN) tables store data column-wise in cloud object storage, optimized for analytical scans. Hybrid tables store data row-wise in a replicated transactional engine inside Snowflake’s services layer, optimized for point reads, point writes, enforced constraints, and secondary-index access.

Do hybrid tables enforce primary keys? Yes. Unlike standard Snowflake tables, hybrid tables enforce PRIMARY KEY, UNIQUE, and FOREIGN KEY constraints at write time. A duplicate primary key insert is rejected.

Can I join a hybrid table to a regular Snowflake table? Yes. A single SELECT can read from any mix of hybrid and FDN tables. The planner pushes the hybrid-side work through the transactional engine’s index access and runs the join in the standard warehouse. This is the killer feature of hybrid tables for analytical workloads that need to combine current state with historical depth.

How fast are point lookups on a hybrid table? Primary-key lookups typically return in 5-15 ms end-to-end at low concurrency. Secondary-index lookups are slightly slower but still in the low-tens-of-milliseconds range. Scan-heavy queries are slower than the FDN equivalent and should be avoided.

How much do hybrid tables cost compared to standard tables? Storage is billed at a higher per-terabyte rate, individual operations incur per-request charges, and compute on the warehouse side is billed normally. The model favors hot, small operational data and penalizes cold, large analytical data. For multi-terabyte tables, standard tables remain materially cheaper.

Can I use clustering keys on hybrid tables? No. Clustering keys are a standard-table concept tied to micro-partition layout. On hybrid tables, the primary key plays the role of physical organization, and secondary indexes accelerate access on other columns.

Are hybrid tables available in all Snowflake regions? No. Hybrid tables are available in a subset of AWS, Azure, and GCP regions and require Enterprise Edition or higher. Check the current Snowflake regional availability for your account before designing around them.

Can I create indexes on a hybrid table after it has been loaded? Yes. CREATE INDEX idx_name ON hybrid_table (col1, col2) works on populated tables. The index is built online without taking the table offline, though large tables take time and consume compute during the build.

Do streams and tasks work on hybrid tables? Yes. Streams capture change data on hybrid tables, and tasks can be scheduled to consume those streams — the same primitives that work on FDN tables. This is the standard pattern for keeping an FDN analytical table in sync with a hybrid operational source.

What happens if I run out of time travel on a hybrid table? There is no fail-safe period on hybrid tables. Once a row leaves the time-travel window — typically up to 1 day depending on edition and configuration — it is unrecoverable without an external backup. Treat hybrid tables the same way you would treat a production OLTP database: have a tested backup-and-restore procedure that does not rely on Snowflake support.

Can I share a hybrid table via Snowflake data sharing? Hybrid tables cannot be shared via standard secure data sharing the way FDN tables can. If consumers in other accounts need to read the data, the usual pattern is to maintain a synced FDN table via streams and tasks and share that.

Wrapping up

Hybrid tables close a real gap in Snowflake’s surface area: the gap between “great analytical warehouse” and “any kind of OLTP.” For the workloads that need millisecond point reads, enforced constraints, and frequent row-level updates, hybrid tables make those operations cheap inside Snowflake and let analytical queries reach the same data without a CDC pipeline. That is a material improvement for teams that were maintaining a Postgres-and-Snowflake split they did not want.

They are not a Postgres replacement. The pricing model assumes hot, small operational data, and the feature set is narrower than a purpose-built OLTP database. The teams that get the most value from them are using them as the current-state side of a current-vs-history pattern — small operational tables joined to large analytical tables, with the join running entirely inside Snowflake on one warehouse.

Before adopting them, validate region availability and edition support, read the limitations doc end-to-end, and measure the cost on a real workload during a proof-of-concept. Once they are in production, monitor HYBRID_TABLE_USAGE_HISTORY weekly for the first month and put alerts on request volume growth — the operational profile of a hybrid table workload changes faster than an analytical one, and the bill follows.

If you are picking the right interface to inspect hybrid tables alongside standard ones, our guide to the best Snowflake GUI tools covers the practical options. For deeper Snowflake-internals reading, reading the Snowflake query profile covers how to read the per-operator stats that tell you whether a hybrid lookup actually used the index you defined, and the Snowflake clustering keys guide covers the analytical-side companion concept. To govern who can read which rows in either flavor of table, the data masking and row access policies post covers the policy primitives that apply equally to hybrid and FDN tables.