Multi-dialect by design: one dataset, five databases

A dataset that only loads into one database isn't a product — it's a personal project. Real analytics teams run on PostgreSQL, SQL Server, MySQL, Oracle, or Snowflake, and often more than one at once. So PrimaForja Supply ships with a ready-to-load schema for every one of them, generated from a single source of truth.

One canonical schema, many dialects

PostgreSQL is the authoritative schema — it's what the generator itself uses. From that one definition, a transpiler emits the equivalent DDL for SQL Server, MySQL, Oracle, and Snowflake. The data (Parquet or CSV) is identical across all of them; only the schema wrapper changes. That means a customer loads the same rows into whatever engine they run, and any difference they see downstream is their pipeline, not the data.

Hand-maintaining five schemas is how they drift. Generating four from one is how they stay in lockstep — regenerate whenever the source changes, never hand-edit the outputs.

The decisions a transpiler has to make

Dialects don't just differ in keyword spelling; they differ in philosophy. A few of the mappings that matter:

• Auto-increment vs explicit ids. Because the data ships with explicit primary-key values, identity/serial columns become plain integer keys — you're loading real ids, not asking the database to invent them.
• Foreign keys. Some engines honor inline REFERENCES; others (like MySQL's InnoDB) need table-level constraints, so the transpiler emits them accordingly.
• Types. Timestamps, numerics, and text types are mapped to each engine's closest faithful equivalent rather than a lowest-common-denominator blob.
• What each engine won't do. Snowflake, for instance, treats CHECK constraints and secondary indexes differently, so the emitter drops what would be inert and documents why.

Base tables first — views as an add-on

The schema comes in layers. The base tables are the dataset: load them and you have the full business. The analytics view layer — the materialized views and KPI tables that power the executive dashboards — is a separate, optional add-on, because not every customer wants it and it's the part that most repays tailoring to a specific BI tool. Keeping the two separate means the core load is simple and portable, and the analytics layer is a deliberate choice rather than baggage.

Why it matters for buyers

Portability is the difference between "evaluate it this quarter" and "file a ticket to get a sandbox provisioned." When the dataset drops cleanly into the database you already run, you can benchmark queries, test a migration, or stand up a demo the same afternoon — on your stack, with your tools, at whatever scale you need. One dataset, five front doors.