Poor database client support

Feedback
1

Can someone explain to me your strategy for database client support? I’m a 20+ year database architect/engineer experienced with most DBMSs. You are pushing people away from using D3 directly for embedding into web pages, towards using Observable as an authoring/display tool, and then promoting code downloads for web page embedding. This seems kludgy and overly complex for web page embedding but that’s a separate discussion and appears to be business driven.

The main issue is that your database client support is extremely limited. I don’t see how you can expect people to adopt Observable without support for Oracle, SQL Server, SQL Azure etc. Sure I can expose data from those sources through a web service but why would I want to take those extra steps?

Postgres is fine but it’s a much bigger world - I have existing databases with millions and billions of rows of data, aggregation tables, extensive analytic code in sql - there is not a chance that data and code will migrate to one of your supported databases. Most tools that use databases have broad support for connections and that is missing for Observable.

Plotly has a Falcon SQL Client connector - I haven’t used it but it seems to be that Observable needs something like it.

Thanks, Tom Kreyche

2 Likes
2

Open-source ideology at work here, I think. They just don’t like the things that make money.

3

We’ve recently put a lot of work into improving the frontend side of the SQL experience on Observable, like the “Data” sidebar pane and the SQL cell type (SQL cells / Observable / Observable). We totally want to support more systems on the backend too. We’re bullish on SQL in general, we’re happy there’s such interest, and we’re sorry it’s currently limited to MySQL, PostgreSQL, Snowflake, and BigQuery, plus SQLite via file attachments.

While this probably doesn’t satisfy your use case, some crafty users have extended our support: DuckDB ❤️ SQL Cells / CMU Data Interaction Group / Observable.

3 Likes