Supported Databases and Compatibility

Database compatibility details matter for predictable team usage. This page clarifies what is supported today and how to avoid confusion. The current production focus is PostgreSQL, including managed Postgres providers.

Primary Target: PostgreSQL

Validation, metadata mapping, and test scenarios are aligned with PostgreSQL syntax and behavior.

Examples and sample datasets are provided for Postgres-style schemas and naming conventions.

Case Sensitivity and Naming

Most production schemas use snake_case lowercase identifiers. Quoted mixed-case identifiers require exact casing.

If a query fails with missing relation or column errors, inspect actual schema object names first.

Query Style Recommendations

Prefer explicit schema qualification and deterministic ORDER BY for reproducibility.

Avoid engine-specific assumptions not aligned with PostgreSQL parser behavior.

Sample Data Notes

Sample schemas are intended for learning and verification, not production benchmarking.

Confirm table and column naming directly before copying example queries into your environment.

Future Compatibility

If additional engines are introduced, they should be documented with explicit behavior differences and test coverage scope.

Until then, treat PostgreSQL as the authoritative compatibility baseline.

Dialect Scope and Feature Availability

SQL Runner uses PostgreSQL as its authoritative dialect. That means query examples, parser assumptions, and compatibility behavior follow PostgreSQL semantics rather than MySQL or SQLite defaults. PostgreSQL features that are commonly used in diagnostics are supported, including CTEs with WITH ... SELECT, window functions with OVER and PARTITION BY, EXPLAIN for plan inspection, array operators, and JSON extraction operators such as arrow and arrow-arrow-greater for nested document fields.

Some capabilities are intentionally out of scope for this utility even in PostgreSQL ecosystems. Stored procedures, user-defined function deployment, temporary table workflows, COPY-based bulk transfer, and privileged pg_catalog access patterns that require superuser roles are not part of the supported browser inspection model. SQL Runner is designed for read-oriented troubleshooting, not full administrative control. Teams needing advanced database operations should switch to dedicated clients with explicit privilege governance and audit controls.

Cross-Dialect Translation Strategy

Teams migrating from MySQL or SQLite should apply a deliberate translation strategy before running queries in PostgreSQL-oriented tools. Rewrite dialect-specific syntax, validate date and string function differences, and ensure GROUP BY semantics are explicit. Translation should be tested with representative result expectations, not assumed from superficial syntax compatibility. This reduces migration friction and prevents subtle logical errors that pass parsing but produce misleading analytical output.

Create a short internal compatibility guide listing the most common rewrites your team needs, such as LIMIT OFFSET style, identifier quoting conventions, and null-handling behavior. Referencing this guide during query review helps engineers avoid repeated mistakes and speeds up onboarding for contributors new to PostgreSQL semantics. Compatibility documentation is a force multiplier when multiple teams share the same read-only diagnostic surface.