doc/user: add LibreDB Studio to SQL clients - #38680
Closed
kaya-abdullah wants to merge 2 commits into
Closed
Conversation
LibreDB Studio connects to Materialize over the PostgreSQL wire protocol. The SQL editor works fully, including Materialize specific statements. The object browser and monitoring dashboard both depend on PostgreSQL catalog objects Materialize does not have, so those two are called out as not working rather than left to be discovered.
Contributor
|
All contributors have signed the CLA. |
Author
|
I have read the Contributor License Agreement (CLA) and I hereby sign the CLA. |
materialize-bot
added a commit
to MaterializeInc/cla
that referenced
this pull request
Sep 5, 2026
Contributor
|
Appreciate you testing this and opening a PR. Given the number of restrictions I suggest we hold off documenting this as a supported integration. |
kaya-abdullah
added a commit
to libredb/libredb-studio
that referenced
this pull request
Sep 6, 2026
…DB instead of crashing MaterializeInc/materialize#38680 (adding LibreDB Studio to their SQL-clients docs) was closed by the maintainer over the size of the "does not work" list: the object browser and the whole monitoring dashboard were unavailable there. Live-verified against real Materialize 26.40.0, RisingWave 3.0.3, CockroachDB v26.2.6, PostgreSQL 18.1, TimescaleDB 2.29.2 and YugabyteDB 2.25.2.0 instances: - getSchema()/getSchemaList()/getSchemaRelations() now retry through a chain of fallbacks matched against whichever error actually comes back, not a fixed order: the reserved MATERIALIZED keyword (Materialize, RisingWave), a missing pg_total_relation_size() builtin (CockroachDB, and Materialize once past the first gap), and missing json_agg()/json_build_object() (Materialize only has the jsonb_ forms). This recovers real table/column data on Materialize and CockroachDB where the object browser previously showed nothing at all. - getHealth(), getOverview(), getPerformanceMetrics(), getSlowQueries() and getActiveSessions() now isolate every pg-statistics-catalog query in its own try/catch, matching the existing pg_stat_statements idiom. An engine with no statistics catalog at all used to reject all four of getMonitoringData()'s "core" reads in full, which made the entire Monitoring page show a connection-error screen even though getHealth()'s own badge degraded fine. - Materialize's own mz_catalog/mz_internal schemas join the existing pg_catalog/information_schema/pg_toast exclusion list everywhere it appears, so the object browser isn't flooded with dozens of internal relations. RisingWave's object browser remains unavailable for an unrelated reason (its query binder rejects the LEFT JOIN pg_class ON (...)::regclass pattern outright) - documented in compatibility.ts and postgres.md, not fixed here. compatibility.ts and docs/providers/README.md are updated to the newly measured tier/caveats for CockroachDB, Materialize and RisingWave.
cevheri
added a commit
to libredb/libredb-studio
that referenced
this pull request
Sep 6, 2026
…roring Closes the two restrictions MaterializeInc/materialize#38680 would still have had to disclose after the schema and monitoring fixes. The object browser asked for BASE TABLE only. Materialize reports its materialized views through information_schema.tables as MATERIALIZED VIEW and they are what its users work with, so the browser showed three plain tables and hid revenue_by_region. The filter stays a positive list, so FOREIGN and SYSTEM VIEW rows still stay out. Measured no-op elsewhere: PostgreSQL leaves materialized views out of information_schema.tables altogether, and the other five engines emit no such table_type. getTableStats, getIndexStats and the tablespace read now answer no rows when the engine says a pg_ object is not there, the rule getSlowQueries and getActiveSessions already followed. The predicate needs an absence phrase AND a pg_ name, because Cloudberry refuses these same queries with a planner restriction while the catalog is readable - reading that as empty would claim the database has no tables. Verified both ways: Materialize's seven monitoring tabs render with no engine error, Cloudberry's two still carry theirs. Not fixed, and now written down: row counts read 0 for every Materialize object because pg_class.reltuples answers -1 and getSchema clamps a negative to 0. Stock PostgreSQL hits the same clamp on a freshly loaded table until autovacuum runs.
Author
|
Could not reopen this one (the reopen API rejected it and there was no reopen button for me either), so continued in #38687 with the fix for the restrictions above. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
LibreDB Studio is an open source, browser-based SQL IDE that connects to Materialize over the PostgreSQL wire protocol. This adds it to the SQL clients page alongside DataGrip, DBeaver and TablePlus.
Description
Added a
### LibreDB Studiosection after TablePlus. The SQL editor works fully, including Materialize specific statements likeSHOW MATERIALIZED VIEWSandSHOW SOURCES. The object browser and monitoring dashboard both fail, called out honestly in a warning block:MATERIALIZEDis a reserved keyword that breaks the schema introspection query, andpg_stat_activity/pg_statio_user_tablesdo not exist, so the monitoring panel cannot read them.