DEV Community: Databasin News

The SQL editor and notebooks, rebuilt: tabs, versions, and real .ipynb files

Databasin News — Sun, 16 Aug 2026 00:40:14 +0000

Two of the surfaces you spend the most time in got rebuilt.

The SQL editor

Tabs that run independently. Start a long query in one tab and keep writing in another — each tab owns its own run state instead of the whole editor going busy. Cmd/Ctrl+T for a new tab, Cmd/Ctrl+W to close, Cmd/Ctrl+1–9 to jump.

Run all, with one result sub-tab per statement, so a script of six statements gives you six sets of results instead of only the last one. There's a real Cancel — including "stop all running queries" when you've started more than you meant to.

Scripts have versions. Saved server-side, with history you can look through and share, because "I had it working an hour ago" should be recoverable.

Once results are on screen, you can work with them without re-querying: filter, pick columns, or open Summary for per-column types, null counts, distinct values, and ranges. Export CSV or JSON, chart it, save the results to your lakehouse, or turn the statement straight into an automation.

Notebooks that speak Jupyter

The important thing about a notebook feature is whether your existing notebooks work in it and whether your new ones can leave.

Import accepts real nbformat 4.x files, mapping the kernel and keeping cell ids where the format carries them. Saved outputs are dropped — you get the code, and you re-run it against your own data. Export emits valid nbformat 4.5, which means nbconvert, nbdime, and GitHub's own renderer all read what comes out. Not a lookalike format; the actual one.

An older nbformat 3 file is rejected by name, with an explanation. The alternative — importing it as a silently empty notebook — is the kind of small dishonesty that costs someone an afternoon.

The full modal keyboard layer is there: Esc and Enter for command and edit modes, A/B to insert, J/K to move, Y/M to change cell type, C/X/V to copy, cut, paste, Z to undo, Shift+M to merge. Plus a cell command palette, cross-cell find and replace, a table of contents built from your markdown headings, and Run this section.

Cells run SQL, Python, PySpark, and Scala against your lakehouse.

When a cell breaks

An errored cell offers Explain this error and Fix this cell — and a fix arrives as a proposed change you can Accept, or Accept and run. It doesn't rewrite your cell behind your back.

Worth knowing

Notebooks carry a Beta badge, and they've earned the honesty that goes with it: Python cells can't be interrupted once running — SQL cells can — and all tabs in the editor share a single connection, so you can't put a Trino tab next to a Databricks tab.

Everything else is exactly what it looks like. Open the SQL editor, hit Cmd/Ctrl+T, and start.

Snowflake key-pair authentication is here — before you need it

Databasin News — Sun, 16 Aug 2026 00:39:40 +0000

Snowflake is phasing out password authentication for service users. If a pipeline of yours signs in to Snowflake with a username and password today, that pipeline has a clock on it.

The Databasin Snowflake connector now supports key-pair authentication. Pick Key Pair as the auth type, paste your private key, and you're done.

What you fill in

Three fields, one of them optional:

Username — the Snowflake user the key belongs to
Private Key (PEM) — the key itself
Private Key Passphrase — only if your key is encrypted

Encrypted and unencrypted keys both work. If your security team hands you a passphrase-protected key, it goes in as-is; if it doesn't have one, leave the field blank.

Password authentication is still there and still first in the list, so nothing you already have changes. This is an option you take when you're ready, or when Snowflake makes the decision for you.

It works everywhere the connector works

The part that's easy to get wrong — and that we specifically went back and fixed — is that an auth method has to work on every path, not just the one you test first. A key that passes Test Connection and then fails when you browse for a table is worse than no support at all, because you find out halfway through building something.

Key-pair auth works across testing the connection, browsing schemas and tables, previewing data, and every scheduled ingestion run.

Where the key lives

Your private key is stored in the same managed secret vault as every other credential you give Databasin. When a run needs it on disk, the file is created with owner-only permissions before a single byte is written to it, and removed when the process exits. It is never written to a log.

One thing to know

Live federation — querying Snowflake as a live catalog without syncing — is still password-only today. If you use both, the ingestion side can move to key-pair now, and the live side needs to keep its password until we finish that work. We would rather tell you that than let you find it on a Friday.

If you run Snowflake, this is worth doing ahead of the change rather than during it — check Snowflake's own guidance for the dates that apply to your account. Open the connector, switch the auth type, paste the key.

The OCR task: turn a folder of PDFs into a lakehouse table

Databasin News — Sun, 16 Aug 2026 00:39:37 +0000

Some data never arrives through an API. It arrives as a PDF: the course catalog, the invoice, the statement, the scanned report somebody emailed you. The numbers are right there, in a table, on page 14 — and the only integration anyone has ever offered you is a person retyping it.

OCR is a new task type in Automations. Point it at a folder of PDFs, describe the fields you want, and it writes rows to a lakehouse table on your schedule.

You describe fields, not layouts

There is no template to draw, no anchor text to configure, no zone to box off. Under Fields to Extract you list what you want and what it means:

course_code — the catalog identifier, e.g. BIOL 2010
credit_hours — number of credits; blank if the course is listed as variable

Those descriptions are the control surface. They go to the model as instructions, so the way you sharpen extraction is by saying what you mean more precisely — not by re-teaching a layout every time the vendor redesigns their PDF. Layout doesn't matter. The table can sit anywhere on the page, and it can sit somewhere else next quarter.

Every page, every run, with receipts

Each page is rendered and read by a vision model — there's no text-layer shortcut that quietly skips scanned documents. You pin which model does it, GPT or Claude, in the task's LLM connector.

Every row lands with provenance attached: source_file, source_page, source_last_modified, source_uri, extraction_confidence, plus the automation, task, and run that produced it. When a number looks wrong, you can get to the document it came from instead of arguing about it.

Turn on Archive PDFs for citations and the source document is stored alongside the data, so Databasin One can open the source document when it cites the row in an answer.

It only reads what's new

Runs are incremental by default, and the watermark is the output table itself — the task asks your own data what the newest document it has already read is, and starts there. No separate state to corrupt, nothing to reset. A document that fails doesn't advance the watermark, so it gets picked up on the next run instead of being silently skipped.

Long documents are handled in windows rather than one giant request, so a 200-page catalog is a normal input rather than a failure.

Fits where your other tasks fit

It's a task card on the same automation canvas as your SQL, dbt, notebook, and agent tasks. Chain it after a file drop, run it nightly, deliver what it produces however you deliver everything else. The output is an ordinary Iceberg table in your lakehouse — every engine and every dashboard can read it the moment it lands.

Beta, and honest about it

OCR ships as beta. Some specifics worth knowing before you point it at something important:

PDFs today. Not images, not Office documents.
Every extracted field is text. Casting to numbers and dates is downstream work, the same as any other raw landing table.
extraction_confidence is a triage signal, not a calibrated probability. Use it to sort what a human should look at, not to certify accuracy.
The target is your Databasin lakehouse in this version.

Documents are the last place where "we have the data" and "we can query the data" are still different sentences. This closes some of that gap — and it does it with the rest of your pipeline, on your schedule, in your warehouse.

Build one in Automations → add a task → Intelligence Tasks → OCR.

Point at a database, get a pipeline: ingestion that works itself out

Databasin News — Sun, 16 Aug 2026 00:39:03 +0000

Setting up ingestion has always asked you to answer questions you can only really answer by digging: which of these tables can load incrementally, which column reliably tracks change, which columns make a row unique, is this file a CSV or something that merely looks like one.

Nobody enjoys that part. So Databasin now does the digging and shows you what it found.

Two screens instead of six

The database flow went from five or six screens down to two, and the file flow from three to two. You pick what you want to bring over, and the review screen arrives with a proposed plan for each object.

Sixteen database connectors are on the new flow, including Epic Clarity, along with five storage connectors for the file lane — SFTP, S3, ADLS, Box, and SharePoint.

It reads the evidence, it doesn't guess from names

The easy version of this feature is to look for a column called updated_at and hope. That approach breaks quietly and expensively.

Instead, detection reads real catalog metadata and runs bounded, read-only probes — a strict overall time budget, per-statement limits, and a hard rule that it never runs count(*) on your tables. Row counts come from statistics catalogs or they don't come at all.

The heuristics are the interesting bit, because they encode the mistakes:

SQL Server's rowversion is excluded as a watermark. It looks perfect and it isn't — it's a binary counter, not a time.
A candidate watermark that hasn't moved in 90 days while a sibling creation column has been updating gets flagged as stale rather than trusted.
A nullable candidate isn't silently accepted — it's either paired with a creation-date sibling or probed for nulls first.

For files, Databasin samples several files per pattern rather than trusting the first one, and takes the consensus for format, delimiter, and header. When the files disagree with each other, it says so — mixed_dialect, header_disagreement — instead of picking one and letting you discover the problem in production.

"Files like this"

Turn any single file into a wildcard pattern with one click, and see how many files currently match before you commit to it.

And a small rule that removes an entire category of silent failure: a pattern that matches zero files won't save. The pipeline that runs green forever and never brings in a row is not a mystery we're willing to keep shipping.

You still decide

Detection is a recommendation, not an act. Every proposal is shown with what it was based on, and the file lane requires you to confirm before anything is created. Files default to a full snapshot; incremental loading is something you turn on, not something inferred on your behalf.

That's the line we're drawing: the machine does the tedious investigation, and you keep the judgment. You should be approving a plan you can see the reasoning for — not filling in six screens of fields you'd have to run experiments to answer honestly.

Connect a source and see what it proposes.

Diagnose with AI: failed runs that explain themselves

Databasin News — Sun, 16 Aug 2026 00:39:00 +0000

A failed run tells you it failed. Finding out why has always meant reading logs written for whoever wrote the code, not for whoever has to fix it at 8am.

Diagnose with AI turns that into a button. It's available on pipeline runs, artifacts, and automation runs.

The classification happens before any AI does

Before a model is involved at all, a deterministic classifier labels what went wrong: an empty configuration, an empty window, schema drift, a malformed URL, an authentication failure, a quota problem, or something transient.

That matters for two reasons. Failures that have a definite answer get the definite answer, and the explanation you read afterwards is anchored to a real classification instead of a model's impression of one.

Your credentials never reach the model

This is the part we care most about, and it works the way it should rather than the way that's easy.

Evidence is redacted on the server, before it is sent to your browser or to any model. Not filtered in the UI. Not trusted to a prompt.

Raw response-body dumps and Spark row dumps are dropped entirely — not masked, dropped — because a body dump is the single most likely place for your actual customer data to be sitting in a log. On top of that, URL query strings, bearer tokens, database connection credentials, SQL literals in WHERE clauses, email addresses, and long digit sequences are all redacted before the payload leaves the server.

Container logs are a separate, opt-in step. Nothing pulls them automatically.

An AI feature that reads your logs is ordinary now. One that does the redaction on the server — before the payload leaves it, rather than trusting a prompt to behave — is the version worth shipping.

Proposed fixes, never applied fixes

For request-configuration problems — a wrong route, base URL, method, parameter, or header — Databasin can go further and propose the correction. It arrives as a field-by-field diff: here's what you have, here's what it should be, here's why.

You review it and you save it. In the product's own words: nothing is changed automatically.

And a proposal is only badged Verified when the corrected request actually reached the vendor and came back healthy. If it couldn't be proven, it says so, and tells you what wasn't verified. A confident-sounding wrong answer is worse than no answer, so an unproven fix has to look unproven.

What it won't pretend to fix

Auto-Fix handles request configuration. Credential problems, transient failures, and schema drift are diagnosed and explained, then explicitly handed back with what needs to happen instead — rather than a fix that looks plausible and isn't.

The goal isn't a product that claims to repair itself. It's the end of reading a stack trace to find out that somebody renamed a column.

Databasin One goes with you: hand your chat to your phone

Databasin News — Sun, 16 Aug 2026 00:38:26 +0000

The question you needed an answer to rarely waits until you're at your desk. It shows up in the hallway on the way to the meeting, or in the meeting, five minutes after you closed the laptop.

Two changes ship together to fix that. Your chats are now saved, and you can hand the one you're in to your phone.

Your conversations are saved now

Until this release, a chat with Databasin One lived in the browser tab and died with it. Now every conversation is stored to your account, per project, and appears in a strip above the chat — click any one to pick it back up.

A saved chat remembers more than the words. Each one keeps its own warehouse connection, its own data context, and its own settings, so reopening a conversation from three days ago puts you back in that conversation's world, not your most recent one — and you can re-run any answer in it against live data.

We cap it at 10 saved chats per project, per person — start an 11th and the oldest one makes way. It's a chat history, not an archive, and the cap keeps it fast.

Continue on phone

In Databasin One's sidebar there's a new action: Continue on phone. It opens a QR code you scan with your phone's camera. You can also copy the link, or have it emailed to you.

Sign in on the phone and you land in the same conversation — not a fresh chat that happens to be in the same project. The thread is there, the project is there, the warehouse is there. Ask the next question from wherever you're standing.

It works for workspace chats the same way. Hand off from a workspace and the phone opens that workspace's session, with the same save controls and session picker your desktop has.

Add it to your home screen

The phone experience is a proper installable app: Databasin on your home screen, opening straight into Databasin One. Add it once from the handoff screen and it's a one-tap thing forever.

There's no separate mobile account and no separate mobile network path. It's the same sign-in and the same permissions you already have, and queries take the same governed route to the same warehouse. For teams whose phones sit behind a VPN, that matters: nothing new to allow, nothing new to secure.

What it isn't

The phone is built for asking and reading, not authoring. You get the conversation, the answers, your dashboards — and the ability to keep going. You don't get the full desktop surface, and that's the point: the meeting doesn't need a dashboard builder, it needs the answer.

Open Databasin One, look for Continue on phone, and scan.

Automate this conversation: turn an answer into a scheduled report

Databasin News — Sun, 16 Aug 2026 00:38:23 +0000

There's a particular kind of work that never shows up in a job description: you ask the questions, you find the answer, and then you do it again next month. Same questions, same joins, newer numbers, and a fresh afternoon gone.

Databasin One now offers to take that job. When a conversation has done something worth repeating, there's an Automate this action — in the chat sidebar, and on the answer itself. Click it, and the conversation becomes a scheduled report.

Everything happens over the chat

The modal opens already filled in, because the conversation is the specification. No wizard, no second screen, nothing to rediscover somewhere else.

It carries the questions you actually asked, the tables you were working against, and — the important part — the SQL that already ran successfully. Not a guess at what you meant. The queries that worked, on your data, minutes ago. The modal says so plainly: carries N queries that already worked in this conversation.

What you fill in is the small stuff:

Questions it will keep answering — your turns, numbered, editable
How often — every weekday morning, every Monday morning, first of the month, or the start of each quarter
Who gets it, and whether they get an email, a PDF, or both
Only send when there is something worth reporting — for the reports that should stay quiet on a normal week

Preview before you commit

Preview report runs the same request the schedule will run — same skill, same queries, same budgets — against live data, right then. What appears in the modal is not a mockup. It's the document, rendered: this is what each run will deliver, built from live data just now.

That matters more than it sounds. A scheduled report that turns out wrong is a special kind of annoying, because you find out on a Monday in front of other people.

Only then does Create automation save it. The two-step is deliberate — this thing will email other people on a schedule, so nothing is created until you've seen what they'll get.

The design is ours, the content is yours

The interesting engineering here isn't that a model can write a report. It's that the same spec always produces the same document.

The model supplies content and structure — the headline figure, which comparison matters, what the finding actually is. It does not supply appearance. It can't: the renderer doesn't sanitize a color out of the model's output, it rebuilds the document from a fixed vocabulary of named blocks and never reads anything else. A stray color, font, or snippet of HTML isn't stripped; it's simply never looked at.

The vocabulary is ten blocks — a hero figure, stat tiles, sections, prose, a composition bar, charts, report-card tables, callouts, bullets, and a fine-print block for sources and row counts. Series colors are positional, so the model never names one. Chart types are an enum, and anything unrecognized becomes a column chart rather than an argument.

There's a nice detail in there: a stat's delta is colored by what it means, not by its sign. Costs up 8% and revenue up 8% are not the same news. Unstated, it renders neutral rather than guessing.

And if a spec comes back malformed, the report is rejected wholesale and the run falls back to the plain markdown it always sent. There is no half-rendered document.

Reports that survive being printed

Every chart is drawn as an image at twice its display size and embedded directly in the document, which is why the PDF looks like a document rather than a web page that lost a fight with a printer. The whole layout is built to survive the trip from HTML to PDF intact.

Ask for both in the modal and the styled report arrives as the email body and as a PDF attachment.

The same machinery, just easier to reach

None of this is a separate product. It creates an ordinary agent automation running an ordinary skill, on the same canvas as your SQL, dbt, notebook, and OCR tasks — same read-only tools, same query budgets, same audit trail per run. You can open it later and edit it like anything else.

And you can go the other way: Report Composer sits in the skills library as a preset, so you can copy it into any agent task you build by hand — which is also how you point it at Slack, Teams, or a write-back to your lakehouse instead of email.

What changed is the distance between having a good answer and having it forever. It used to be a project. Now it's a button.

Ask Databasin One something worth asking twice, then look for Automate this.

Agent skills, rewritten: see it, name it, own it

Databasin News — Sat, 08 Aug 2026 19:55:18 +0000

When we shipped AI agents as an automation task type, a skill was something you picked from a dropdown and hoped for the best. You could see its name and one line of description. You couldn't see what it actually told the agent to do, you couldn't change it without an admin, and a skill written in one project was invisible in every other one.

This release fixes all of that. A skill is now a product object you own.

See it before you run it

Selecting a skill renders its full instructions, read-only, right in the task config. That's the whole system prompt: what it looks at, how it reasons, what it must never do. No more running something you can't read.

Name your own copy

Databasin's own skills (executive summary, data-quality summary, anomaly and root-cause explainer) are gold copies. Picking one always makes you a copy, and you name it something meaningful before anything is created. Your library stays yours; ours stays pristine. Your copy keeps its lineage too, so when we improve the original you'll see "update available" and decide whether to take it.

Edit it where you use it

A skill you customize inside an automation belongs to that automation. Edit its instructions, its description, and the inputs it asks for, right there in the task. No second screen, and no change in behavior for anybody else. Every save is a new version.

Choose who else gets it

Three scopes, and widening is one click:

Just this automation. Your copy, your tuning, invisible in everyone else's picker
This project. The team on this data can run it and fork their own
Your whole organization. Every project sees it

Skills authored in the library default to org-wide, because that's how most teams actually think about them. Anyone who can work in a project can write one. No admin ticket. Admins keep an org-wide governance view of everything that's been built, including the private per-automation tuning, with one-click promotion for the ones worth sharing.

Skills now declare their own inputs

Previously every skill asked for the same three things — a table, some starter SQL, a prompt — whether it needed them or not. Now a skill declares its own fields, and the task form is generated from them: table pickers, dropdowns, numbers, free text, whatever it actually needs. Multi-table selections now reach the agent intact.

Same guardrails, same blast radius

None of this widens what an agent can do. Still three read-only tools, still SELECT-only on every query, still your turn limit and query budget, still a full audit trail per run. The data connection is chosen by the task, never by the skill. A skill anyone can write is still a skill that can only read.

See how agents work →

Live sources: query your tools the moment they connect — no sync required

Databasin News — Sat, 08 Aug 2026 19:54:43 +0000

Until today, every source followed the same path: connect, sync, then query. Live sources removes the middle step.

Connect a supported source and it shows up as live tables the moment credentials pass, with no pipeline and no waiting for a first sync:

SELECT company, SUM(amount) AS open_pipeline
FROM live.hubspot.deals
WHERE stage != 'closedlost'
GROUP BY company
ORDER BY open_pipeline DESC;

That query runs directly against the API, right now, with your filters pushed down to the source where it supports them.

What's live

SaaS tools, rolling out now across the native connector catalog. The product shows you exactly which of your sources support live; everything supports sync
Databases: Postgres, MySQL, MariaDB, SQL Server, Oracle, and Snowflake federate the same way, as live catalogs
Everywhere you query. Live tables work in the SQL editor, notebooks, and Databasin One, and they join your synced lakehouse tables in a single statement

Live and sync are partners, not rivals

Live is built for the first hour: exploration, quick questions, "is this data any good?" You get insight in minutes instead of after the first pipeline run. Sync is built for everything after — full history, big scans, gold views, dashboards that need to be fast at any volume. Connect once, use both.

Ask your first question before your first sync finishes. Try it now: $50 in credit, no card.

Express signup: one email field, and your workspace is waiting

Databasin News — Sat, 08 Aug 2026 19:54:39 +0000

Getting started used to mean a signup form. Now it means one field.

The box turns up all over databasin.ai: the hero, the sticky bar, any page. Type your email and click once. We build your workspace and send your sign-in link. That's the whole flow:

Your email, the only thing we ask for up front
Check your inbox for the sign-in link, which arrives from welcome@databasin.ai
Sign in with Google or Microsoft. Name your organization on first login and you're looking at your own workspace with $50 in credit

No credit card. No company-size dropdown. No "a member of our team will reach out."

Already have an account? The same field recognizes you and sends a sign-in link instead — it's the fastest way back in, too.

Five minutes from the email field to your first cited answer. The field is right here.

AI agents join Automations: put a skill on a schedule

Databasin News — Sat, 08 Aug 2026 19:54:02 +0000

Databasin One answers questions when you ask. As of this release, it also works when you don't: AI agents are now a task type in Automations.

A skill is a versioned, shareable package of instructions. An agent task runs one against your governed data, on your schedule, in your workflow. Chain it after your pipelines refresh; deliver what it produces to email, Slack, or Teams.

Starter skills, ready to schedule

Executive summary reads the fresh numbers, writes the narrative, builds the charts, ships the PDF. Monday, 7am, already in Slack
Data-quality check sweeps your tables for gaps, drift, and surprises, and files the report
Anomaly explanation takes a metric that moved, traces which segment and which source, and shows the query that proves it

Skills are managed like code. They're versioned, shareable across the team, and curated by your admins. Run one with a click in Databasin One, or let an automation run it forever.

Automation you can audit

Agents run with guardrails, not vibes: read-only tools, query budgets, and row caps. Every run writes a full audit trail of what it read, what it ran, and what it produced. If a number's in the summary, the receipt is in the log.

One more task card on the same canvas as your SQL, dbt, and notebook tasks — drag it into a stage and go.

Two weeks of polish: global dashboard filters, connection credentials, Doris everywhere

Databasin News — Sat, 08 Aug 2026 19:53:56 +0000

Not every release is a headline feature. This one is a stack of the small things that make daily work smoother.

Dashboards

Global filters — one filter bar drives every tile on the dashboard, with a clear-filter pill so you always know what you're looking at.
Tiles can stretch the full modal width, drag no longer risks closing the view, and the exit affordance is unmistakably labeled.

Lakehouse

Connection Credentials viewer — connect BI tools, IDEs, or scripts directly to your lakehouse engines. Trino, Apache Doris, Spark, DuckDB and Databricks each get their own credentials, shown sanitized, with key management where the engine supports it.
Notebooks stream Apache Doris results as they're produced, the same as Trino.
Cluster dialogs now show the live IP whitelist, so you can see who can reach a cluster while you're editing it.

SQL editor

The executing-statement highlight now stays on the statement that's actually running, with no more bleed onto the previous line.

Small fixes, shorter days.