Replay
Databases: PostgreSQL, DuckDB and SQLite in one console
A real run, replayed: one console over PostgreSQL, DuckDB and SQLite. The builds behind it hold 27 repeatable changes across two databases with 18 tables each. [PostgreSQL migrations]
Your data in a database you own and can question.
For owners paying monthly to reach their records: a database designed around your work, backed by 27 numbered, repeatable changes across two databases. [Postgres]
Sound familiar
Your Monday export lands in a spreadsheet. You still need another report to answer your question. Back to the platform: change the filters, download another file. You spend your time assembling records instead of using them.
We plan a database around your records and the questions you need answered. Start with the report you keep rebuilding. Show which fields it needs and what the current export leaves out.
Out of the platform
Your customer records, invoices or membership history determine what needs to move. We assess exports from a customer management tool, a business operations system or an association management system. [CRM, ERP, AMS]
The work follows these steps: collect your records, reshape them, upload them, add custom fields and connect your apps. Collection uses permitted access through the platform's app connection, export files or your own logged-in screens. [API]
Some platforms make leaving hard, so we check first that the access reaches the whole database. Anything with an API or a CSV upload is a candidate to move, with bulk reshaping before the upload. The review compares another platform's features and ongoing cost.
We also add a browser console for exploring the database. It lists tables with row counts, shows how tables link, then runs a question and shows the result. Customer records, large-file analysis and research each use database software suited to the job. Bring an export file or connection details to the migration discussion.
The right engine per job
Customer records use one database engine, the phone app another, and the call desk a third. [Postgres, SQLite, DuckDB]
We map your records and their relationships, write numbered changes, then add queries for search and analysis. The work includes backups and a restore check before release. Each change describes what happens to the stored data.
The research database lets you search written content. [SQLite FTS5] The landlord pipeline also checks whether a location falls inside an area. [DuckDB spatial point-in-polygon]
Stored secrets use encryption, and a column supports searches for similar records. [AES-256-GCM, pgvector]
Replay
DuckDB console: tables, SQL, saved queries, CSV export
A real run, replayed: the browser console checks each query and accepts only a single request to read data. [parsed SELECT] Its server carries 14 security tests and 11 tests for simultaneous requests.
The database console lists tables and row counts, saves questions and exports results to a spreadsheet file. [CSV]
Your console walkthrough starts with records for individual pieces of land, their data types and a map of the tables, then covers calculations across groups of records and text search. See the database design example for the engines behind each job.
tenants 8 rows15 tables carry a tenant key, so each business's records stay its own
conversations 64
- conversation_events 261
- leads 39
- conversation_attributes 189
contacts 47
- consent_records 94
- leads 39
leads 39
- outbound_log 90
integrations 13
- webhook_deliveries 30
Settings and logs
- chatwoot_accounts 8
- llm_usage_counters 120
- processed_events 261
- secrets 4
- suppression_list 5
- tenant_chunks 24
- tenant_client_controls 2
- tenant_config_versions 21
Rows recorded from the console.Recorded
Every tenant with its live config version, conversation count and lead count in one pass. PostgreSQL 14.24 · agent_service
SELECT t.slug,
t.lifecycle_state AS state,
v.version AS live_version,
count(DISTINCT c.id) AS conversations,
count(DISTINCT l.id) AS leads
FROM tenants t
LEFT JOIN tenant_config_versions v ON v.tenant_id = t.id AND v.status = 'active'
LEFT JOIN conversations c ON c.tenant_id = t.id
LEFT JOIN leads l ON l.tenant_id = t.id
GROUP BY t.slug, t.lifecycle_state, v.version
ORDER BY leads DESC, t.slug;
| slug | state | live_version | conversations | leads |
|---|---|---|---|---|
| osgood-water-systems | active | 3 | 10 | 7 |
| confluence-water-recovery | active | 3 | 9 | 6 |
| prairie-line-radon | active | 1 | 9 | 6 |
| sand-creek-basement-recovery | active | 3 | 8 | 5 |
| uncompahgre-foundation-works | active | 3 | 8 | 5 |
| red-rock-lower-level-design | active | 1 | 6 | 4 |
| poudre-gate-ironworks | paused | 1 | 7 | 3 |
| ten-mile-heating-air | active | 3 | 7 | 3 |
Group by a value inside the captured JSON and count the urgent ones with FILTER. PostgreSQL 14.24 · agent_service
SELECT capture_snapshot ->> 'service' AS service,
count(*) AS leads,
count(*) FILTER (WHERE capture_snapshot ->> 'urgency' = 'emergency') AS emergencies,
min(created_at)::date AS first_seen
FROM leads
GROUP BY 1
ORDER BY leads DESC, service
LIMIT 8;
| service | leads | emergencies | first_seen |
|---|---|---|---|
| basement finishing | 3 | 0 | 2026-09-26 |
| helical pier underpinning | 3 | 2 | 2026-09-21 |
| sewer line lining | 3 | 1 | 2026-09-21 |
| class 4 water damage | 2 | 1 | 2026-09-27 |
| multi suction point radon | 2 | 1 | 2026-09-30 |
| sub slab depressurization | 2 | 0 | 2026-09-16 |
| sump pump installation | 2 | 1 | 2026-10-02 |
| wet insulation removal | 2 | 0 | 2026-10-07 |
Postgres full-text search over each tenant's knowledge chunks, ranked by relevance. PostgreSQL 14.24 · agent_service
SELECT t.slug,
c.source_ref,
round(ts_rank(to_tsvector('english', c.content), q)::numeric, 3) AS rank,
left(c.content, 78) AS excerpt
FROM tenant_chunks c
JOIN tenants t ON t.id = c.tenant_id,
websearch_to_tsquery('english', 'insurance OR warranty OR permit') AS q
WHERE to_tsvector('english', c.content) @@ q
ORDER BY rank DESC, t.slug
LIMIT 8;
| slug | source_ref | rank | excerpt |
|---|---|---|---|
| red-rock-lower-level-design | faq.md | 0.025 | Q: Do you handle permits? A: Yes. Design drawings, permit applications and ins |
| confluence-water-recovery | faq.md | 0.02 | Q: Do you work with insurance? A: Yes. We photograph the loss, keep daily mois |
| confluence-water-recovery | services.md | 0.02 | Confluence Water Recovery handles class 3 and class 4 water losses with moistu |
| poudre-gate-ironworks | faq.md | 0.02 | Q: Can an existing gate be automated? A: Often yes; we check hinges, posts and |
| prairie-line-radon | faq.md | 0.02 | Q: How do I know it worked? A: We retest after installation and the system car |
| sand-creek-basement-recovery | faq.md | 0.02 | Q: Can you install a sump pump? A: Yes. We size the pump to the pit, add a bat |
| ten-mile-heating-air | faq.md | 0.02 | Q: How long does a furnace swap take? A: Most replacements finish in one day a |
| uncompahgre-foundation-works | faq.md | 0.02 | Q: Do I need an engineer? A: Our plans are engineered for each house. Every pi |
At scale
County records show how a large collection became records for individual pieces of land. In all, 3,361,791 raw county records became 1,391,184 records from nine county sources.
Replay
Lead scraping pipeline: eight-stage replay
A real run, replayed: the eight-stage call-list pipeline takes 46 listings to 31 leads split across three sales people.
The call-list process marks duplicates without deleting them, so separate locations of a chain stay callable. Records missing both phone and email stay out of the call-ready list. The process records why it excludes each record.
Replay
Rental lead manager: ranked call desk
A real run, replayed: a call desk ranks records in one HTML file of about 700 KB. Keys 1 to 8 log outcomes and move to the next record.
The call desk shows properties and roof ages behind each name. You can undo an outcome entered incorrectly.
We connect data collection to a business app built around the decisions you need to make with those records.
A small CRM in SQLite
A public feed supplies records for this working example of a small tool for keeping leads and customers. [CRM, SQLite] Pick a feed of public software activity, encyclopedia edits or new stories. [GitHub, Wikipedia, Hacker News]
Live
Live API-to-CRM integration showpiece
An interactive example: public-feed records pass through four timed stages into a small database.
The server fetches the records, puts them in a common format, removes repeats and saves them, here from public feeds.
A separate panel receives messages from another app. It accepts correctly signed messages and rejects forged signatures. It ignores an event identifier it has already received. [Webhook]
Your database starts with one specific task: receive a record, check it and make it available to answer a useful question. We define that work before adding other connections or building a larger interface.
Done for someone else
We delivered this kind of work for clients. The console and pipeline above show how we work.
Tell us what you would change
Name the platform holding your records and the question you cannot answer. We reply with the proposed scope of the database work.