SQL
The standard language for relational data for over four decades. PostgreSQL now handles JSON, full-text search, and vector operations alongside traditional queries.
ClearView
The universal language for data
SQL has outlived every language proposed to replace it, and nearly every system of record still speaks it. The language is declarative: a query names the data wanted and the planner chooses how to fetch it, so the difference between a fast system and a slow one usually sits in how well the schema and the planner are understood.
Modern SQL carries far more than rows and joins. Window functions and common table expressions handle analytics in place, and PostgreSQL adds JSONB documents, full-text search and pgvector embeddings inside the same transactional engine. A schema with real constraints enforces correctness continuously: foreign keys, checks and unique indexes reject bad data at write time, which costs less than any cleanup after the fact.
A relational engine remains the right default for a system of record, and PostgreSQL is where our recommendations usually land. The wrong-choice cases sit at the edges: lookups that need cache speed belong in a key-value store such as Redis, and columnar analytics across terabytes belong in a warehouse built for scans, such as Snowflake.
SQL was used by 58.6% of respondents to the 2025 Stack Overflow Developer Survey.
PostgreSQL publishes one major release each year, and each major version receives fixes for five years.
- Data Modelling
- Query Optimisation
- Reporting
- Database Migration
Our SQL capabilities
Schema design & normalisation
Schema design is where data quality is decided, so we normalise for integrity first and denormalise only where a measured read path justifies it. JSONB columns carry the variable parts of a record without giving up the relational core, and temporal tables preserve history where an audit trail is required.
- PostgreSQL
- Star schema
- Temporal tables
Query performance engineering
Performance work starts by reading plans: EXPLAIN ANALYZE against data shaped like production rather than a developer copy. The fixes follow from what the plan shows, covering and partial indexes matched to the actual predicates, queries rewritten where the planner has no good option, and PgBouncer pooling where connection churn is the real cost.
- EXPLAIN ANALYZE
- PgBouncer
- Index tuning
Database migration & replication
Engine migrations run staged, with change data capture through Debezium keeping the old and new databases in step while reads move across gradually. Oracle and SQL Server sources go through schema conversion and a parallel-run period, so cutover happens only after the two systems have been shown to agree.
- Debezium
- CDC
- AWS SCT
Why Adaca for SQL?
Financial data integrity
Transaction processing, ledger systems, and regulatory reporting where ACID compliance is non-negotiable.
PostgreSQL deep expertise
JSONB indexing, GiST/GIN indexes, row-level security, and pg_stat_statements for performance monitoring.
Oracle & SQL Server migration
Migration to PostgreSQL or Aurora using AWS SCT with parallel-run validation.
Managed database operations
RDS, Aurora, Cloud SQL with automated backups, read replicas, and failover testing.
Data modelling for compliance
Audit trail schemas, retention policies, and encryption-at-rest for regulated data obligations.
Query review in CI
Automated EXPLAIN plan analysis in CI, flagging sequential scans and N+1 patterns before production.
Common Questions
Should we migrate from Oracle to PostgreSQL?
The case is usually licence cost, and it is often strong, with the caveat that the migration is a project rather than an export. PL/SQL packages, Oracle-specific functions and behavioural differences around transactions all need conversion and testing, work that schema conversion tooling starts but never finishes.
The staged pattern removes most of the risk: convert and validate schema by schema, replicate changes continuously so both databases stay current, run in parallel against production traffic, and cut over per workload once the outputs match.
Can PostgreSQL replace our document and search databases?
Often, yes. JSONB with GIN indexes covers most document workloads, built-in full-text search covers most search features, and pgvector covers similarity search over embeddings, all inside the transactional database the application already runs. Consolidating removes a synchronisation pipeline, which is usually where the defects lived.
The exceptions are search that needs deep relevance tuning and document volumes far beyond the relational data. Those justify a dedicated engine; most workloads never reach them.
Can AI coding tools write production SQL?
They can, and the database hands them better context than most languages offer: the schema, its constraints and its indexes are machine-readable facts an agent can load before writing a line, and EXPLAIN output shows it what the planner actually did. That makes generated SQL unusually checkable.
The trap is dialect drift. The public corpus mixes MySQL, SQL Server and PostgreSQL, so generated queries can carry another engine's functions or subtly different semantics. Generated queries run against the real engine before review, and CI flags plans that fall back to sequential scans. The measured results of our AI-augmented delivery flow are on the Technology page.
How is SQL work priced?
Either as a fixed cost for an initial outcome, such as a first release or a defined migration, or as a monthly rate for the team once later phases are under way. We do not publish a figure for a build, because the scale is set by the number of features, platforms, user groups and users, and projects have run from four weeks to several months. The How We Charge page sets out both models, milestone billing and the notice period.
What does the team for SQL work look like?
Typically one full-time engineer on the build, with two part-time roles alongside: one running the project and one working with you on priorities and technical decisions. Teams are shaped around the system rather than around one technology, so SQL work draws in the neighbouring stack when it needs to. Delivery starts under Australian leadership, with the engineering in our Manila delivery centre.
How quickly can SQL work start?
Discovery establishes the scope, systems involved and delivery requirements. We agree the implementation plan and timing after that work, before implementation begins.