u/OkShirt9372

Product catalogs are often cited as examples of where document databases fit well. A laptop and a T-shirt may share only a few fields, so putting every possible attribute into a single fixed table can result in a wide schema with many empty columns.

A common setup is to keep orders and payments in a relational database and store the catalog in a document database such as MongoDB.

Databricks makes the case for the other route in a recent piece that I was reading on relational vs non-relational databases: keeping the catalog in PostgreSQL and using a JSONB column for attributes that vary across products. That keeps the flexible fields next to the common fields and lets the catalog remain part of the same relational system as orders and payments.

The choice seems to depend on how the data is queried.

If most requests retrieve one product by ID with all its attributes, a document database may fit that access pattern well. If the application needs to filter, group, join, or aggregate across product attributes, keeping the data in a relational system may make those queries easier to manage.

For anyone who has used JSONB for a product catalog, when did it start to become difficult?

Was it indexing fields inside the JSON, inconsistent attribute names, validation, schema changes, or queries that became difficult to maintain?

And for those who moved the catalog to a document database, what made the separate system worthwhile?

We’ve been experimenting with a slightly different approach to Playwright testing: instead of hard-coding every browser interaction, can an AI model decide what action to take next based on the current page state?

We tested this with Jev across 15 realistic end-to-end scenarios from a Playwright tutorial repository.

The setup was:

Playwright handled browser sessions, fixtures, setup, and verification.
Jev received the test goal, success criteria, accessibility snapshot, and available actions.
It selected actions such as clicking, filling inputs, checking controls, navigating, waiting, or stopping.
Playwright executed those actions and passed the updated state back to Jev.

The results were mixed. Jev passed 72 out of 150 runs, or 48%, with independent Playwright verification. Some short workflows worked consistently, while others were flaky, and six scenarios never passed.

The experiment suggests that fully replacing scripted Playwright tests is probably still impractical. Converting browser state into model inputs loses significant information, and deterministic assertions remain important.

However, a hybrid approach seems more promising. For example, Playwright could handle setup and verification while an AI model handles a dynamic section of a workflow, such as a changing third-party checkout.

The full write-up includes the test setup, controller loop, benchmark results, and limitations:

https://endform.dev/blog/jev-playwright-testing

We wanted to know if you would use an AI-selected action loop for part of a Playwright test, or if the unpredictability is too costly for your test suite.

Would you use JSONB or a separate document database for a product catalog?

We tested whether Jev could choose Playwright actions at runtime