TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Prediction market: We're unhappy with Firestore. What will we switch to?

43 点作者 akrolsmir大约 3 年前

11 条评论

jpgvm大约 3 年前
Unless you need realtime PostgreSQL is always the most obvious solution.<p>If you do need realtime you can build it on PostgreSQL yourself depending on your requirements either using LISTEN&#x2F;NOTIFY or logical replication. There are tradeoffs to both if tbh if you are asking this question you probably don&#x27;t want to go that path.<p>Non-realtime it&#x27;s very easy to handle nested JSON in PostgreSQL but I would still avoid it like the plague unless it&#x27;s user-supplied data without any real schema.<p>You might feel like schema-less lets you &quot;move faster&quot; but it&#x27;s a load of horseshit that really starts to stink much sooner than you might think.<p>Schemas and by extension database integrity make it easier to move faster because migrations allow you to ensure there are no edge conditions related to stored data when upgrading your code to use an extended or otherwise modified data model.<p>The other main benefit of PostgreSQL is just the sheer body of resources available, with the exception of the other main RDBMS (MySQL&#x2F;MSSQL) it just completely dwarfs what is available for other data stores. You will rarely if ever encounter a problem someone hasn&#x27;t already solved.
评论 #30731544 未加载
评论 #30732481 未加载
评论 #30731543 未加载
com2kid大约 3 年前
&gt; - Related: Firebase cloud functions have extremely slow cold-start times (&gt;5 seconds is common), and deploying new versions can take minutes.<p>This somehow has gotten a lot worse. When I first started with Firebase Cloud Functions, which to be clear are amazing and simple to get up and running with compared to anything competitors offer, it was a few seconds to deploy. Sadly it has gotten worse and worse as time goes on.<p>Still though, the paradigm around cloud functions is so <i>simple</i> compared to the nightmare that is AWS Lambdas. When trying to explain why cloud functions are better, AWS users just stare at me like I am talking in a foreign language about some sort of mythical land of make believe.
评论 #30731803 未加载
akrolsmir大约 3 年前
More context: The main thing I&#x27;m unhappy with is the extra developer burden imposed by needing to denormalize information. E.g: I have a user document in Firestore, with userId, name, and avatarUrl. If I want to be able to fetch a list of comments and have the name &amp; avatarUrl of the creators, in Firestore I have to write those alongside userId. Then, if I later add isVerified to the user document, I need to either backfill my entire db and denormalize again; or client-side handle the missing case.<p>Then the other pain point is the &quot;joins&quot; use case; right now we do the equivalent of fetching all comments &amp; users, then doing an in-memory join. Ideally, we could craft a single request that just says &quot;get the 10 latest comments on this market, plus the associated avatars&quot; without data duplication and without doing a bunch of up-front thinking about exactly how to structure indexes.<p>My hesitation with relational DBs comes from the mismatch between client data model (loosely, JSON objects of pointers) and how it&#x27;s represented in the DB (in a row); plus the requirements of needing to specify your e.g. indices up front, and annoyance of doing migrations. I&#x27;m hopeful someone&#x27;s found a graph-type solution to work really well for them!
评论 #30730514 未加载
评论 #30730876 未加载
评论 #30731698 未加载
评论 #30732689 未加载
评论 #30732014 未加载
bo1024大约 3 年前
1) Any thoughts on the conflict of interest? Any insider can easily take advantage of a market like this.<p>2) Is there any element of a decision market here? Are you asking users to just predict, or help you decide? The incentives change a lot in the latter case, since one can get cyclic dependency -- self-fulfilling prophecies.
评论 #30731118 未加载
latchkey大约 3 年前
Firestore has very specific usecases that don&#x27;t match a lot of things that Postgres is really meant to handle. Namely, as you are learning the hard way, it isn&#x27;t a relational database. It doesn&#x27;t make it bad, it just isn&#x27;t what you thought it was. $1400 a month is nuts, it sounds like something isn&#x27;t optimized well.<p>GCP Cloud SQL (Postgres) has been fantastic for me. Easy to connect to, easy to scale and not that expensive.<p>I have GCP Cloud Functions (golang) in front of that and they spin up, connect to the database and serve the whole request in under 1s. Hot requests are 80ms for submitting some simple data.<p>If you do it right, you can minimize persistent connections to the SQL backend (offload as much as possible to PubSub messages which a backend function can handle). This will keep your bills down too because you won&#x27;t need as large of an instance to serve requests.
antifa大约 3 年前
I wish GCP had 2 things. A dumber key-value-store&#x2F;mongodb-clone thing. Firebase has too much going on with it&#x27;s confusing await getCollection().getDocument().getSnapshot().data() thing, the half documented transition to composition API, and I didn&#x27;t need realtime.<p>Also a serverless postgres offering. Not even the fancy kind. There are some great free tiers outside of GCP. I have some projects where my usage would, if given true pay-as-you-go pricing, would fairly be between $0.10&#x2F;month and $25&#x2F;year. But GCP starts at $9&#x2F;month for a postgres and a lot of competitors just leap straight to $25&#x2F;month when leaving the free tier.
评论 #30732190 未加载
评论 #30731336 未加载
评论 #30730801 未加载
satyrnein大约 3 年前
The site sounds neat, and using the site to answer this question about itself is amusingly meta. I&#x27;m not sure if M$ are 1:1 dollars or even real money, so I wanted a FAQ or something, but there&#x27;s only a sign up form (on mobile), which I&#x27;m certainly not going to do for something that might just be a Hollywood Stock Exchange type of game. This is all probably intentional, but letting you know just in case!
评论 #30734087 未加载
jasfi大约 3 年前
You could use PostgreSQL with your own back-end. Related to this, I&#x27;m working on an SDK for Flutter that works via REST and is quite easy to use: <a href="https:&#x2F;&#x2F;nexusdev.tools&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nexusdev.tools&#x2F;</a>
tqkxzugoaupvwqr大约 3 年前
Tip: You can avoid saving the avatar url if you use a predictable url like &#x2F;avatars&#x2F;:userId instead of something like &#x2F;avatars&#x2F;:randomToken
gerardnico大约 3 年前
<a href="https:&#x2F;&#x2F;fly.io&#x2F;docs&#x2F;reference&#x2F;postgres&#x2F;" rel="nofollow">https:&#x2F;&#x2F;fly.io&#x2F;docs&#x2F;reference&#x2F;postgres&#x2F;</a>
xrd大约 3 年前
Do you mean Firebase or Firestore?<p>If you mean Firestore, what about minio? It&#x27;s incredibly scriptable and awesome.<p>If you mean Firebase, use rxdb and connect over graphql (hasura is fantastic) to your postgres database. It can be a little work to understand how the models all map into the database, but once you get it, it&#x27;s magical.<p>Both are easy to self host. I run my entire stack of all components on dokku, so I get easy logging, backup, and can migrate to a new host in a few standard commands.