Limitations with Postgres Data Reflection

Self-Host
1

Hi NocoDB team and community,

We’re evaluating NocoDB for our organization but have encountered what appear to be fundamental limitations with the Postgres Data Reflection feature. These issues are potential deal-breakers for our adoption.

Issue 1: Non-Configurable Schema Naming

NocoDB creates schemas using base IDs (e.g., pd3r9cggvw555a4, pe692u2ogu3fokj) which creates several problems:

  • database pollution: Our DBAs see these as cryptic/spam-like entries

  • no semantic meaning: Impossible to identify which schema belongs to which project

  • breaks naming conventions: Conflicts with our existing database standards

Is schema naming configurable or on the roadmap?
This is essential for company environments.

Issue 2: Incomplete Table Discovery/Reflection

Despite documentation claiming “everything is perfectly mirrored,” NocoDB only displays tables created through its UI.

Evidence from our testing:

  • Database contains 4 tables: Table-1, Table-2, newtable, organization_test
  • NocoDB UI only shows 2 tables: Table-1, Table-2
  • Tables created via DDL (newtable, organization_test) are invisible in UI
  • All tables have same owner (nocodb) and exist in same schema

This breaks critical use cases:

  • cannot use foreign tables
  • cannot use database migrations
  • cannot create views or other database objects we created from others schemas.

This seems to contradict the “Data Reflection” feature entirely - it’s more like “UI-Created Table Reflection” only.

  1. Is full bi-directional schema reflection actually supported?
  2. If not, are there plans to implement true database reflection?
  3. Are there any workarounds to make externally-created tables visible?

We’re excited about NocoDB’s potential, but without true database reflection, we cannot proceed with adoption as it would require rebuilding our entire data infrastructure through the UI.

Looking forward to clarification on whether these are known limitations or if I am missing something in my setup.

p.s.: also curious about the NC_DISABLE_PG_DATA_REFLECTION environment variable. How would behavior change if we disable it?

Currently, we’re using NC_DB with this configuration:

json

{
  "client": "pg",
  "connection": {
    "host": "postgres.hostname",
    "user": "nocodb",
    "password": "PASSWORD",
    "database": "database_name",
    "schema": "schema_name"
  },
  "searchPath": ["schema_name"]
}

Would disabling data reflection force NocoDB to use our specified schema instead of creating new ones with base IDs? And would this potentially solve the table visibility issue?

2

Thank you for your interest in NocoDB. I’d like to clarify some misunderstandings about the Postgres Data Reflection feature and address your concerns.

Understanding the True Purpose of Data Reflection

The Postgres Data Reflection feature isn’t designed to reflect external DDL changes into NocoDB. Its primary purpose is to ensure that what you see in NocoDB’s UI matches exactly what’s in your Postgres database without obfuscating table and column names.

Schema Naming Clarification

  • Schema names using base IDs (like pd3r9cgvw553a4) cannot be changed - this is by design

  • This approach allows each base to have its own dedicated schema in Postgres

  • The naming convention is fixed and not configurable

Why This Approach?

Our primary user persona is business users who interact with NocoDB as a spreadsheet-like interface, not developers writing SQL directly. However, the Data Reflection feature provides significant value for:

  • Technical teams who need to connect BI tools like Tableau, Looker, or Metabase to NocoDB data

  • Organizations requiring direct database access without dealing with obfuscated table/column names

  • Enterprise customers who need transparency in data storage (many are already using this feature)

Regarding Your Issues

  1. About Schema Naming: The non-configurable schema naming is intentional and won’t be changed, as it maintains a clear separation between bases

  2. About Table Visibility: The Data Reflection feature isn’t meant to make externally created tables visible in NocoDB. It’s specifically for ensuring NocoDB tables are properly reflected in Postgres with clear names

  3. About the Environment Variable: Setting NC_DISABLE_PG_DATA_REFLECTION to true would store everything in the NC_DB database without one-to-one mapping of table/column names, which won’t solve your table visibility issue

Recommendation

If your primary requirement is to see and work with externally created tables in NocoDB, Data Reflection may not be the right solution for your use case. We don’t recommend modifying the underlying NocoDB native base directly with SQL.

We’ll improve our documentation to make these distinctions clearer. I appreciate your feedback as it helps us identify areas where we need to provide better explanations of our features.

If you’re an enterprise organization evaluating NocoDB for adoption, I’d be happy to schedule a discovery call to discuss your specific requirements and how NocoDB might fit into your technology stack. We can explore customized solutions that align with your organization’s needs.

3

Thank you for the offer and for your detailed explanations - they’ve been very helpful in understanding NocoDB’s architecture and design philosophy.
At this stage, we’re still in the early evaluation phase and need to build a small proof-of-concept to demonstrate the value internally before we can consider any broader adoption discussions. We’re not quite at the point where enterprise-level conversations would be appropriate, as we first need to validate the technical fit with our specific use cases.

4

Regarding the user persona you mentioned - we have a mixed team of business users and developers who support their needs. The main needs we have is that we have some ‘master data’ datasets that we want to use for references in specific bases.

1. Cross-schema reference challenge:

Let’s imagine there is a schema masterdata with a table organizations that contains a list of our current clients and partners (display name, primary contact, etc.). There might be a sales team who creates a base Sales and wants to connect to this masterdata.organisation table to reference it from other tables inside the base (to display full official name, address, etc.). Also, there is a finance team who creates a Finance base in NocoDB and also wants this masterdata.organisation in their base. The primary need is to display some values using references (aka the linksfeature in NocoDB).

The problem I have with external datasource connection in NocoDB is that I can connect to schema masterdata only once, so the masterdata.organisation table will be only in one base, either Finance or Sales. Also, it’s not clear how to ensure cross-schema references.

Have you faced any use case similar to ours?

I am thinking of trying foreign tables in PG to address these two concerns: creating dedicated schemas for both bases (noco_finance and noco_sales), and adding masterdata.organisation as a foreign table to each. Then creating two NocoDB bases and establishing external datasource connections from each respective noco_... schema to its corresponding NocoDB base.

edit: I was thinking of just creating views in target schema, but views don’t support foreign key constraints.

Is there any better solution to try?

2. External datasource setup:

Having said that, could you advise on the proper setup with external datasources? I do like having metadata stored in our PG, but don’t want to have a new schema created each time users create a new base. We plan to enforce users to use external datasources within their bases (and probably disable the Default datasource option). Should I just set the variable NC_DISABLE_PG_DATA_REFLECTION = True during installation but keep NC_DB_JSON with PG schema for metadata?

5

I understand your challenges with cross-schema references and external datasource configuration.

1. Cross-schema reference with external Postgres database:

We’re currently building a PostgreSQL sync feature that will soon be available in NocoDB. This feature specifically addresses your use case by allowing you to sync tables/views from external databases into your NocoDB bases.

With this upcoming feature, you’ll be able to:

  • Maintain your master organization data in a single PostgreSQL schema

  • Sync this data to different NocoDB bases (Sales, Finance, etc.)

  • Each department can then work with the data that’s relevant to them

We’re already using this feature in our cloud environment with excellent results (though it hasn’t been rolled out to all users yet). Our internal tests show it handles large datasets well - we’re syncing over 100,000 rows in total. The system is optimized to sync only updated records each time, making it quite efficient.

This approach will eliminate your current limitation of connecting to the masterdata schema only once, as each base will have its own synchronized copy of the data that stays updated automatically.

2. External datasource setup:

For your question about external datasources, yes, you should disable PostgreSQL data reflection by setting the variable NC_DISABLE_PG_DATA_REFLECTION = True during installation. This will prevent NocoDB from creating a new schema each time users create a new base.

3. Cross-base Reference for NocoDB Bases

I should also mention that we do have cross-base reference functionality currently available for NocoDB native bases in private beta. This feature allows you to reference data across different NocoDB bases without requiring external database syncing.

This cross-base reference feature is currently being tested with select customers. The early feedback has been very very positive, but I want to emphasize that this capability only works with NocoDB native bases - not with external database connections.

This means that if you’re using NocoDB’s built-in storage (rather than connecting to external databases), you can create references between different bases, allowing teams to share and reference data across organizational boundaries while maintaining their separate workspaces.

Another Solution to Consider

One practical approach you could implement today is to create a dedicated NocoDB base specifically for your organization master data, and then use our cross-base reference functionality to connect this data with your Finance and Sales bases.

This would work as follows:

  1. Create a new NocoDB “Organization” base containing your master organization data

  2. Set up your Sales and Finance bases as separate NocoDB native bases

  3. Use the cross-base reference feature to link the Organization base to both the Sales and Finance bases

This solution gives you a single source of truth for your organization data while allowing different teams to work in their own specialized bases. It avoids the limitations of external datasource connections while providing the reference functionality you need.

All of the above new features will be only available in our cloud and on-prem enterprise versions.

1 Like
6

Thanks @Navi for the clarification. Based on your response, I have a few follow-up questions about it:
regarding 1. Cross-schema reference with external Postgres database:

When you mention the upcoming Postgres Sync feature - will this enable true bidirectional sync where:

  • Changes in Postgres (made outside NocoDB) → appear in NocoDB UI
  • Changes in NocoDB UI → update Postgres

also, can it sync data between on base and multiple external data sources? or its only one-to-one sync?

regarding 2. External datasource setup:

yes, you should disable PostgreSQL data reflection by setting the variable NC_DISABLE_PG_DATA_REFLECTION = True during installation. This will prevent NocoDB from creating a new schema each time users create a new base.

if I store metadata in a PG schema but disable PG reflection, where data will be stored (from tables created in ‘native’ Nocodb bases) - there will be created one PG schema to store all tabular data or Nocodb will stored these data inside docker container?

When to expect to have these features released in one-prem enterprise version?