Databases & Data Systems: SFIA levels and developer seniority
Fennec team · 23 Mar 2026 · 4 min read
Every application is, underneath, a bet on how you store and query data. Database work tends to be invisible until it is the reason for an outage or a page that takes ten seconds to load. Getting it right is a mix of schema design, query performance, and knowing which trade-offs a given database was built around.
SFIA levels for data work move from running the queries you're given, to owning schema design for a service, to eventually setting an organisation's whole approach to data.
1
Level 1: Follow
“I can run basic SQL queries and understand what a relational database is. I know data is stored somewhere but haven't designed a schema.”
The evidence here is foundational: SQL queries you wrote for a task with a reviewer's guidance, a completed course on relational databases or SQL fundamentals, or notes from someone explaining why a particular index exists on a table you were working with.
Learning to read a query plan, even at a basic level, pays off early and often. Write your first schema for a small personal project, and ask someone to walk you through why an index was added to a real table rather than just accepting that it's there.
2
Level 2: Assist
“I write queries, make schema changes, and perform routine database tasks with some guidance. I understand indexes exist and why they matter.”
Look for independence on routine work: schema change pull requests you made with review, routine database tasks like migrations or backups completed by following a runbook, or an index you added with a before-and-after measurement to show it mattered.
Write a migration yourself end to end rather than pairing on one, and learn the practical differences between at least two database types you actually use, Postgres and Redis is a common pairing. Add an index to a slow query and measure the difference, numbers make the point better than intuition.
3
Level 3: Apply
“I design schemas, write and optimise complex queries, implement backups, and resolve database issues without help. I understand the trade-offs between different database types and can pick the right one.”
Design starts to matter here: a schema you designed from scratch for a real service, a slow query you diagnosed and fixed with the numbers to prove it, or a backup or restore process you implemented or tested yourself rather than assuming it works.
Owning a database's schema and performance for a service, not just contributing to it, is the shift that tends to follow. Run a query performance audit and fix the worst offenders, and write down the trade-offs behind a database choice you made, since that reasoning is often as valuable as the choice itself.
4
Level 4: Enable
“I own the database architecture. I design for scale, plan and run migrations without downtime, and advise the team on data modelling decisions. I'm consulted when there's a hard database problem.”
The evidence reaches further now: a scaling or migration project you led, sharding, replicas, or a zero-downtime migration, and data modelling guidance you gave that shaped another team's design, or being the person consulted on the hardest database problem going.
Leading a migration with no downtime, start to finish, is a strong marker at this level. Write a data modelling guide your team actually uses, and document your reasoning the next time you're consulted on a hard problem, since writing it down is what lets your judgement scale beyond the room you're in.
5
Level 5: Ensure & Advise
“I define data architecture standards across multiple systems. I lead the organisation's approach to data management and governance.”
At this level the evidence spans systems, not services: a data architecture standard adopted across multiple systems, a governance framework you defined, or a cross-system schema review process that exists because you built it.
Write a data standard that spans more than one system, and build a review process for schema decisions across the organisation rather than leaving them to individual teams. Mentoring other engineers on data architecture is usually part of the job by this point, even if it isn't in the title.
6
Level 6: Initiate & Influence
“I set data strategy and architecture at an organisational or enterprise level.”
The evidence at the top is strategic: an enterprise data strategy you set, external recognition through talks, writing, or advisory work, or standards that outlived the specific system that originally prompted them.
From here, publish your data architecture thinking externally, own data strategy at the organisation level, and aim for standards designed to outlast any single system, including the one you're working on right now.
Go deeper
A practical, vendor-neutral guide to SQL indexing.
Free university-level lectures on database internals.
A weekly newsletter of PostgreSQL news and articles.
Knowing where you sit is one thing, proving it later is another. Fennec lets you log databases & data systems evidence as you go, a shipped feature, a decision, a review, tagged to the level it demonstrates, so the case for your next step is already made when you need it.