AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms10 business days
To start a SQL engagement
Scoping through first sprint
100%
Senior engineers, US-based
No offshore handoff
Every sprint
Working software on a preview URL
Not a status deck between milestones
100%
Code and infrastructure you own
From the first commit
Where SQL work fits
What a SQL engagement is actually building
"SQL developer" covers a wider range of work than the term suggests — from designing a schema before any application code exists to tuning a query that's been slow in production for months.
Schema design
Deciding which tables exist, how they relate, and which constraints the database itself enforces rather than trusting application code to get right every time. Get this wrong early and every later feature inherits the cost of working around it.
Query and index tuning
The single highest-leverage lever for database performance, and the one most often skipped until something is already slow. Reading an actual query plan — not guessing — tells you whether a missing index, a bad join order, or an unnecessary full table scan is the real cause.
Database migrations and platform moves
Moving an on-prem SQL Server or Oracle database to a managed cloud database, or off a proprietary engine to PostgreSQL to shed licensing lock-in, is one of the more common reasons a SQL specialist gets called in — and the dialect differences between engines are exactly where a naive migration breaks.
Reporting and analytics queries
Turning transaction data into something a business can act on, often against a separate analytics warehouse (Snowflake, BigQuery, Redshift) rather than the transactional database directly, so heavy reporting queries don't compete with production traffic for the same resources.
Stored procedures and database-side logic
T-SQL, PL/pgSQL, and PL/SQL each let you put logic inside the database itself — useful for enforcing rules close to the data, and a genuine maintenance liability when overused for logic that belongs in the application layer instead. Knowing which is which matters more than knowing the syntax.
Testing and data integrity
Constraints, foreign keys, and transactions that actually get used — not just declared — are what keep a database honest under concurrent writes. A database that "mostly" enforces its own rules is one bad migration away from silent data corruption.
Decisions that matter
The design decisions that decide whether a database stays fast as it grows
SQL is forgiving early and unforgiving later — a schema and index strategy that works fine at ten thousand rows can fall over at ten million, and the fix after the fact is far more disruptive than getting it right up front.
SQL is a standard, not one product
PostgreSQL, MySQL/MariaDB, SQL Server, and Oracle all implement core SQL, and each adds its own dialect on top — window functions, JSON handling, and procedural extensions (PL/pgSQL, T-SQL, PL/SQL) all differ between them. Code written against one doesn't run unmodified against another, which matters the moment a migration or a multi-database integration is on the table.
Normalization, deliberately broken when it earns its keep
Normalizing a schema to reduce data duplication is the right default. Deliberately denormalizing a specific table for read performance is a legitimate, well-understood trade-off — the mistake is doing it by accident, inconsistently, without knowing which tables are which and why.
Indexing is the highest-leverage performance decision
The right index on the right column turns a full table scan into a lookup, often the difference between a query that takes seconds and one that takes milliseconds. Too many indexes slow down writes; too few slow down reads — this is a decision to revisit as query patterns change, not a one-time setup task.
Reading the query plan, not guessing
EXPLAIN or EXPLAIN ANALYZE (naming and exact syntax vary by engine) shows what the database is actually doing to answer a query — which indexes it used, where it scanned instead of seeking, where time is actually going. Tuning a slow query without reading its plan first is optimizing blind.
Transactions and isolation levels
Wrapping related writes in a transaction is what keeps a database consistent when something fails halfway through. The isolation level controls how much concurrent transactions can see of each other's uncommitted changes — the default is usually right, and getting it wrong under real concurrent load is a subtle, hard-to-reproduce bug rather than an obvious one.
Migration tooling and zero-downtime schema changes
Versioned migration tools track schema changes the same way source control tracks code. On a live production database, changes that lock a large table need an expand-and-contract approach — add the new structure, backfill, cut over, remove the old — rather than a single blocking change that takes the application down mid-deploy.
What's involved
SQL and database engagement types
What sets the real scope is less the row count than what's actually wrong or missing — an unindexed schema, a database that's outgrown its current engine, or a migration between two systems that don't speak the same dialect.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| Schema and query performance audit | Fixed scope | 1 – 2 weeks | A review of schema design, indexing, and slow-query plans against your actual production query patterns, with a prioritized fix list. |
| New schema and database design | Fixed scope | 3 – 8 weeks | A schema designed for a new application or feature, including constraints, indexing strategy, and migration tooling from day one. |
| Query and index optimization | Fixed scope | 2 – 6 weeks | Targeted tuning of the specific slow queries and missing indexes an audit identifies, verified against real query plans, not estimates. |
| Database platform migration | Fixed scope | 6 – 16 weeks | Moving a database between engines or to a managed cloud platform, including the dialect and stored-procedure differences that a naive migration misses. |
| Dedicated database engineer | Staff augmentation | Ongoing | A senior SQL/database engineer embedded in your existing team, working your sprint cadence. |
Ranges assume US-based senior engineers. The audit is the fastest way to find out whether a slow database needs targeted index work or a genuinely different schema — the two look similar from the outside and cost very differently.
Right tool, wrong tool
When a relational database is the right call — and when it isn't
SQL's strengths are real for the workloads it was built for, and a relational database isn't the automatic answer for every storage problem.
Right call: data with real relationships and integrity requirements
Orders, customers, inventory, financial records — anywhere the relationships between records matter and a partial or inconsistent write is a real problem, a relational database's constraints and transactional guarantees (ACID) earn their cost directly.
Right call: reporting and analytics on structured data
SQL's expressiveness for aggregation, joins, and window functions makes it a strong fit for turning structured transactional data into reports and dashboards — especially paired with a purpose-built analytics warehouse for heavy queries.
Wrong call as the sole store: extreme write-throughput event streams
High-volume time-series or event data — sensor readings, clickstreams — can overwhelm a general-purpose relational database's write path at large scale. Purpose-built time-series extensions (like TimescaleDB on Postgres) or a dedicated event store are often the better fit, sometimes alongside a relational store rather than instead of it.
Wrong call as the sole store: full-text or vector search at scale
Basic text search works in SQL for small data sets, but a real search experience or a similarity search over embeddings for AI applications is usually better served by a dedicated search engine or vector database sitting alongside the relational store, not replacing it.
Depends: loosely structured or rapidly changing data
A document database can be a better fit when the data genuinely doesn't have a consistent structure across records. It's a worse fit when it's chosen to avoid schema design discipline rather than because the data is actually unstructured — a decision worth making deliberately, not by default.
Depends: which relational engine
PostgreSQL, MySQL, SQL Server, and Oracle each have real differences in feature set, licensing model, and ecosystem fit — the right one depends on your existing stack, your cloud provider, and specific features you need, not a universal ranking.
Migration and integration
Where a SQL engagement is really a migration
A meaningful share of database work isn't new design — it's moving an existing database somewhere else, or fixing one that's outgrown its original design.
On-prem to managed cloud
Moving an on-prem SQL Server or Oracle instance to a managed cloud equivalent (Amazon RDS, Azure SQL, Cloud SQL) removes a real operational burden — patching, backups, failover — but the cutover itself needs careful testing against the target platform's specific dialect and configuration differences.
Between database engines
Moving off a proprietary engine to PostgreSQL to shed licensing costs is common, and it's a genuine migration, not a file copy — stored procedures, proprietary functions, and dialect-specific SQL all need to be translated and tested, not assumed to run unmodified.
Unindexed schemas discovered under real load
A schema that performed fine in development or at launch frequently reveals missing indexes or a normalization decision that doesn't hold up once real production traffic and data volume arrive. This is the single most common reason a healthy-looking application suddenly needs database attention.
Zero-downtime schema changes on a live system
A production database that can't take a maintenance window needs schema changes applied through an expand-and-contract pattern — adding new structure, backfilling data, cutting the application over, then removing the old structure — rather than a single blocking migration.
Hiring for SQL work
SQL developer, database engineer, or DBA — and what to look for
"SQL developer" gets used loosely enough that it's worth being specific about what you actually need before you hire for it.
SQL developer
Someone who writes efficient queries and designs schemas as part of building an application — usually a role within a broader backend engineering job, not a standalone specialty. This is what most people searching this term actually mean.
Database engineer
A deeper specialty focused on schema design, indexing strategy, and query performance across an application or a whole platform — the person you bring in specifically because performance or data-integrity problems have outgrown what the application team can fix on the side.
DBA (database administrator)
An operations-focused role: backups, replication, failover, capacity planning, and keeping the database itself running — distinct from writing the queries and schema an application uses. A cloud-managed database reduces but doesn't eliminate this need.
What to ask about, regardless of title
Ask a candidate to walk through how they'd diagnose a slow query — if the answer doesn't involve reading an actual query plan, that's a real gap. Ask about a schema decision they'd make differently in hindsight; a candidate with real production experience has one.
Related
Related services
What SQL and database work usually connects to.
Questions
Common questions about SQL development
What teams ask before a first call.
SQL — Structured Query Language — is the standard language for creating, querying, and managing data in a relational database. It's used to design schemas, write the queries an application runs against its data, build reports and analytics, and enforce the constraints that keep data consistent under concurrent use.
It's not a single product — PostgreSQL, MySQL, SQL Server, and Oracle each implement SQL with their own dialect and extensions on top, which matters the moment you're integrating between systems or migrating from one to another.
It depends most on the shape of the work — a schema and performance audit is the smallest engagement, a new database design for a product still being built sits in the middle, and a full platform migration between database engines is the largest, because dialect differences and stored-procedure translation add real scope.
A scoping conversation, backed by a short audit for any existing database, gets you an accurate number faster than a generic estimate would.
A SQL developer writes efficient queries and designs schemas as part of building an application — usually a role inside broader backend engineering work. A DBA is operations-focused: backups, replication, failover, and keeping the database itself running reliably. Most people searching for a "SQL developer" actually mean the first role, and it's worth being specific about which one you need before hiring.
The most common causes are a missing index on a column a query filters or joins on, a query written in a way that forces a full table scan, or a schema design that doesn't match how the application actually queries the data day to day. The fix depends entirely on which of these is happening, and that's not visible without reading the actual query plan — guessing at a fix without one tends to move the problem rather than solve it.
An audit that reads the slow query plans directly, rather than estimating from the schema alone, is the fastest way to a real answer.
SQL, when your data has real relationships that matter — orders, customers, financial records — and you need transactional guarantees that a partial write never leaves the data inconsistent. A NoSQL document store can be a better fit when data genuinely doesn't have a consistent structure across records, and neither one is the universally correct default.
We'll walk through your actual data model and access patterns rather than defaulting to whichever is trendier this year.
Yes — this is one of the more common requests we get, whether it's an on-prem SQL Server instance moving to a managed cloud database, or a move to PostgreSQL from a proprietary engine to reduce licensing lock-in. The real work is in the dialect and stored-procedure differences between engines, which is exactly what an audit surfaces before a migration timeline gets promised.
Both, depending on the case. Constraints and logic tightly coupled to data integrity — the rules that should hold no matter what application touches the database — often belong close to the data, in T-SQL, PL/pgSQL, or PL/SQL. Business logic that changes often, or that needs to be tested and versioned alongside application code, usually belongs in the application layer instead. Overusing stored procedures for the second category is a common source of hard-to-maintain databases.
You do. Schema, migrations, and any database code live in a repository under your organization from the first commit, and the database itself runs in your own cloud account or infrastructure. That's the arrangement that keeps your data and its structure fully in your control, not dependent on a vendor relationship to access or modify.