Documentation as code
A good fit when the team wants to describe a database model in DBML and publish web-based documentation from that code.
Alternative · dbdocs
A dbdocs alternative that reads the real schema.
dbdocs is useful when the team wants to describe the database in DBML and publish the result. Taavik is useful when the database already exists inside a private network and the documentation should follow it, with change history, manual notes preserved, and no DBML file to maintain in parallel.
Docs as code vs scan-based docs
The source of truth is the key difference.
dbdocs starts from DBML files that describe the database structure. Taavik starts from scans of the actual database metadata, then renders documentation and records changes over time.
Live database scan
A good fit when the team wants documentation generated from the database that already exists inside a private network.
Update DBML or scan metadata
Docs-as-code works when the code stays current. Scan-based docs work when the live database is the reference.
Documentation plus operations
Taavik keeps docs close to saved SQL queries, scheduled exports, and run history.
What changes in Taavik
Documentation is generated from scans and connected to work.
Manual notes stay useful
The generated metadata can refresh while the team keeps its own descriptions and operational notes.
Read the guidePrivate agent scan
The agent scans metadata from inside the network and the workspace renders the documentation.
See how it worksOperational SQL
The same workspace holds the SQL that support, finance, and operations teams reuse.
See shared SQLChoosing
Use dbdocs when DBML is the workflow. Use Taavik when the live database is the workflow.
Taavik is built for teams that already have private databases and want documentation, query reuse, and scheduled exports to follow the database as it changes.
FAQ
dbdocs alternative: docs from live database scans (no DBML)
Is there a free dbdocs alternative? +
Yes. Taavik has a free plan that covers one database connection, one workspace member, and unlimited scans. The documentation is generated from the live schema, manual notes are preserved on refresh, and the change history is included. No DBML file is needed.
What is the difference between dbdocs and Taavik in one line? +
dbdocs starts from a DBML file the team writes and keeps in sync with the database. Taavik starts from a scan of the database itself and writes the documentation from what the scan found. The two approaches suit different workflows, and this page describes when each one is the right pick.
Does the dbdocs alternative work with private databases behind a firewall? +
Yes. The scan runs inside the private network through an agent, and only the catalog metadata leaves the network. No inbound connection is opened towards the database, and the credentials stay sealed in the agent.
Which databases does the scan support? +
PostgreSQL, MySQL, SQL Server, and Amazon Redshift. Provider quirks are normalized at scan time, so the documentation reads consistently regardless of the engine.
Can manual descriptions written in Taavik survive an auto-refresh? +
Yes. Auto-updates touch the generated metadata only. Prose descriptions on tables and columns, and free-text notes on any object, are preserved across scans and follow renames when the diff engine detects them.
How does the change history compare to reading git diffs on DBML files? +
A git diff on DBML shows the intent as written by the person who edited the file. The change history in Taavik shows what actually happened on the database, which is not always the same thing. Both are useful; only one of them survives changes made outside the migration workflow.
Try it
Keep docs and operational SQL in the same Taavik workspace.
Generate documentation from metadata scans, then connect it to saved SQL and recurring exports. The change history behind the docs is described in the piece on schema drift detection.