Using PostgreSQL and Baserow

Feedback
#1

Hi, this is not really a question, I just want to share my experience in case it could help someone else.

It seems I misunderstood what Baserow is. My confusion comes from the use of PostgreSQL. I thought it’s possible to use the underlying database directly in a developer-friendly way and use Baserow more like a DB viewer that non-technical people can edit data in.

But now, upon running it with Docker (after changing the config so I can connect to the DB directly) I see a DB with hundreds of tables, some of them with what seems like test or example data. The two example tables that I see in the Baserow app are in there. But the tables names, columns etc. aren’t directly labelled so I’d have to look them up first.

In hindsight this is all kind of to be expected for it to work as it does but somehow I naively expected something else. I guess the direct DB access is more of a theoretical feature in case you end up really needing it and 99% of the time you would go through the API?

2 Likes
#2

Hey @michael1 ,

I guess the direct DB access is more of a theoretical feature in case you end up really needing it and 99% of the time you would go through the API?

That is true for the most part. We usually recommend people to use the API if they want to interface with Baserow from a technical POV.

That being said, it is possible to use the Database directly as you pointed out as well. The biggest difficulty I see is that the schema is changed at runtime whenever somebody edits their table structure. That’s a great feature for Baserow to work as well as it does, but it does complicate things when you want to rely on a certain schema while using the DB directly.

1 Like
#3

To further clarify what those other tables you see are, they are the tables used by the templates that ship with Baserow by default. If you don’t want these template tables setup you can set the env var BASEROW_TRIGGER_SYNC_TEMPLATES_AFTER_MIGRATION=false starting in a fresh database.

3 Likes
#4

I am having the same problem. Could you please share what was the final solution to this?

I am trying to build a SaaS for supply chain management so accessing the DB tables in an organized manner is critical for me.

#5

From what I understand, Baserow is behaving pretty much like WordPress (people are probably more familiar with that one) where you can see the internals of it once installed and accessed.
In the same way, it will indeed have a lot of “noise” regarding the database and the interesting fields that we may be looking for.

So, I guess that the possibles approaches @dhruv_marketrics are:

  • :cloud: do not access the DB and use the self-hosted Baserow app instance (like you would normally do using the Cloud solution
  • :white_check_mark: use the API provided to you, here is a quick blog post that I wrote to get you started and get something simple but functional
  • :x: mutate directly the tables + remove the noise by setting @nigel’s recommended flag, meanwhile, this is probably the least desirable approach, more details below. :point_down:t2:

Postgre is able to keep track of some edits, so it may work for light edits (like fixing a typo in a text field of an entry).
For the rest aka mutating a table name or something with more database relations, that could be a bad idea bringing odd behavior and a lot of inconsistency. If you want to keep your Baserow stable, don’t use that approach. :see_no_evil: