Replies: 3 comments 1 reply
-
Yes. This is a great use for Materialize. To keep your architecture as simple as possible, I would recommend using Postgres for all your writes, connecting Materialize to Postgres using direct postgres replication. I'd split your workload into three categories: (1) All writes always go directly to postgres. Structure your indexes as minimally as possible with minimal overlap - the only indexes you create in postgres are those that make (1) and (2) faster. The only indexes you create in Materialize are those that make (3) faster.
I don't understand this question fully, so I'd appreciate a bit more clarification as to what you mean. However, using this architecture, I would not create any materialized views in Postgres - only in Materialize. Once you hook this up end-to-end, any indexes/materialized views/etc that you create in Postgres are immaterial for Materialize (and vice versa) - in fact, all they do is slow Postgres down, so I'd strip Postgres of as many indexes as possible - the more indexes you can migrate from Postgres to Materialize, the better.
This is good criticism. You are right that we don't say more on this kind of use. Perhaps we should. |
Beta Was this translation helpful? Give feedback.
-
Thanks for your reply, I will try Materialize this week.
My understanding is I can use any Postgres client to query the materialized views, but the data isn't stored in Postgres, it's in Materialize's proprietary format. I'd assume Postgres is a bit more optimized for If it's significantly faster to query Postgres than Materialize, then it could be worth the lag to update the new table. I'll try it myself once I get Materialize set up. |
Beta Was this translation helpful? Give feedback.
-
You might also want to look at the TAIL command as a way to get the continuous stream of changes to a relation / materialized view, as an alternative to repeated |
Beta Was this translation helpful? Give feedback.
-
Hi, I'm a frontend dev and I've been trying to tackle the issue of efficiently using derived data for an app backend, Materialize looks really promising!
Materialize's website focuses on analytics, streams, microservices, etc. Would it be a good idea for a general cache for derived data in a typical app or website? E.g. some scenarios where Materialize could help a lot:
I'm currently storing some of this data in the database, some of it in cache, and some of it is re-computed for every request. Would it be a good idea to compute all of this using Materialize? It would be much faster to fetch from materialized views than re-computing from the normalized database. In addition, I don't have to worry about manually updating the cached values. I would still have a simple read-through cache on top.
In addition, would reads be faster if I copied the materialized views to Postgres/MySQL/etc, or would it be roughly the same speed to just query Materialize directly?
Beta Was this translation helpful? Give feedback.
All reactions