Database
Career Paths
How to interpret this table?
You may choose this advanced topic if you like doing the things listed under “they usually do”, and you are fine with not doing the things listed under “they usually do not do”.
Alternatively, you may choose it if you are interested in applying for the listed job roles and want to practice work that is close to those roles.
| Job title | They usually do | They usually do NOT do | Real-life examples |
|---|---|---|---|
| Database-focused Software Engineer | Design persistent data storage, model data structures, enforce consistency rules, integrate databases with application logic, write data-related tests | Build user interfaces, design UX, manage product features or visual presentation | E-commerce product database, issue tracker storage layer |
| Data Model Designer | Define schemas, relationships, constraints, and normalization or equivalent design principles | Optimize UI flows, handle client-side state, or design API contracts | Relational schema for ERP systems, graph model for recommendation engines |
| Full-Stack Developer (data-leaning) | Integrate database access into application code, use abstraction layers, handle migrations and persistence | Deep infrastructure ops, large-scale data engineering pipelines | CRUD-heavy business applications, internal tools |
Affected SDLC Phases
If a team chooses this advanced topic, the system design, implementation, and testing phases are most strongly affected, as the focus shifts toward data persistence, modeling decisions, and correctness. Planning emphasizes data requirements and structure. Testing focuses strongly on data integrity and boundary conditions. Deployment is minimal and focuses on database setup and portability.
Affected Tasks
Features are defined
Minimum Viable Product (MVP)
By the end of this task, your team has defined at least six data-related features focused on persistent storage. Each feature must clearly describe what data is stored, retrieved, updated, or deleted, and how persistence is preserved when the application stops and restarts.
Technical Details
Before defining features, the team must choose at least one persistent database technology (e.g. relational, graph, document, file-based, or in-memory with persistence) and state this clearly in README.md.
Use a consistent feature issue template. Each feature must include:
- Data entities or structures involved
- Operations performed (create, read, update, delete, traverse)
- Consistency or integrity rules applied
- How persistence is verified (what survives restart)
Features must be data-centric and end-to-end. Avoid vague items like “set up database” or “store data”.
Quality
High-quality feature definitions clearly explain the data model and its purpose. Design principles such as normalization, single source of truth, or an equivalent approach for non-relational models are explicitly stated and consistently applied. Features are implementable, testable, and clearly tied to persistent behavior.
System is working
Minimum Viable Product (MVP)
By the end of this task, your team demonstrates a working system with persistent data storage. The demo must show that data is correctly stored, retrieved, and remains intact after the application is stopped and restarted.
Technical Details
The demo must include:
- Writing data to the database
- Reading the same data back
- Restarting the application
- Verifying that the data is still present and correct
If a database abstraction or binding layer is used (e.g. ODBC, JDBC, TinkerPop, or similar), this must be shown and briefly explained. The demo steps must be repeatable and documented in README.md.
Quality
High-quality demos show reliable persistence and clear data flow. Data integrity rules are respected, and the database behaves predictably across restarts. Extra quality comes from demonstrating portability, such as switching database vendors or configurations with minimal code changes.
Bug fixing
Minimum Viable Product (MVP)
During development, your team must report and fix one reproducible database-related bug (e.g. incorrect query result, violated constraint, persistence failure, or boundary condition error). The bug must be demonstrated before and after the fix.
Technical Details
The bug report must include:
- Database type and version
- Data setup used to reproduce the issue
- Steps to reproduce (queries or operations)
- Expected vs actual results
Testing must include boundary or range cases (e.g. minimum/maximum values, off-by-one limits, or empty datasets). After fixing, re-run the same tests to prove correctness.
Quality
High-quality bug fixing shows a clear data-related bug lifecycle: precise reproduction, correct diagnosis, and verified resolution. Tests cover boundary conditions (2–3 border limits or range testing). The fix improves correctness without breaking existing data or violating design principles such as normalization or single source of truth.