Skip to content

Conversation

@levkk
Copy link
Collaborator

@levkk levkk commented Jan 22, 2026

Omnisharded tables

We now treat all tables as omnisharded unless they are configured in pgdog.toml. This makes configuration a lot easier. To make this work we load the Postgres schema from system catalogs on boot and inspect it for tables that match the config for each query. This is quick, since the tables (and their columns) are organized in a HashMap.

Schema inference

We now load schema from Postgres on boot and inspect it for sharding keys. To make this work, Postgres needs to be available when PgDog is started.

Migrations

When adding/changing sharded tables, make sure to run RELOAD (or RECONNECT) to reload the schema, otherwise a SELECT against the new table will default to omni, not sharded, for queries that don't provide the sharding key.

Unique ID generation

This has been removed in #727

Added pgdog.unique_id() to Postgres itself (via setup CLI command), so it's now possible to add it as a default to a table, e.g.:

CREATE TABLE omni (
    id BIGINT NOT NULL DEFAULT pgdog.unique_id(),
    value TEXT,
);

How this works:

  1. Configure shards in pgdog.toml
  2. Run pgdog setup to create the function and its dependencies. This will create a schema called pgdog on all shards and the pl/PgSQL functions will be added to it.

Warning

Don't use the Postgres unique ID function to generate sharding keys! They won't match the shard they are generated on. Make sure to call it explicitly in the query so PgDog executes it instead.

@codecov
Copy link

codecov bot commented Jan 22, 2026

@blacksmith-sh

This comment has been minimized.

@levkk levkk marked this pull request as ready for review January 22, 2026 20:40
@levkk levkk merged commit a597083 into main Jan 22, 2026
8 checks passed
@levkk levkk deleted the levkk-default-omni branch January 22, 2026 20:55
levkk added a commit that referenced this pull request Jan 23, 2026
…r omnisharded tables (#727)

### Description

- Removed `pgdog.unqiue_id()` inside Postgres introduced in #725. That
can lead to data loss when used with omnisharded and sharded tables
alike.
- Added `omnisharded_sticky` setting to make omnisharded `SELECT`
queries use the same shard for each client, to avoid schema drift from
the schema cache (e.g. Rails)

```toml
[general]
omnisharded_sticky = true
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants