[HN Gopher] Fly Postgres, Managed by Supabase
___________________________________________________________________
Fly Postgres, Managed by Supabase
Author : samwillis
Score : 267 points
Date : 2023-12-15 11:52 UTC (1 days ago)
(HTM) web link (supabase.com)
(TXT) w3m dump (supabase.com)
| biorach wrote:
| Excellent news
| kiwicopple wrote:
| hey hn, supabase ceo here
|
| Fly's current Postgres offering is unmanaged, so we're working
| with them to run their managed offering. This is the same model
| that they run with the Upstash team for Fly Redis[0]
|
| We're still working with testers to roll out HA features. We
| don't have firm timelines yet unfortunately, but we'll work with
| the Fly team to make it happen as soon as possible
|
| I'll stick around for any questions/comments
|
| [0] Redis: https://fly.io/docs/reference/redis/
| denysvitali wrote:
| Two awesome technologies / companies joining forces!
|
| Supabase and Fly.io are awesome - can't wait to see how cool
| they can get together!
| adam_gyroscope wrote:
| Nice job & congrats!
| pplante wrote:
| You used the lowercase, it's cool we're all friends here in
| your intro. Then reverted to correct casing for the remainder.
| Disarmed everyone with that sly move.
|
| nice touch!
| saintfire wrote:
| It is sort of funny that such an innocuous thing was all I
| could think about while reading it.
| kiwicopple wrote:
| ha, I think I probably wrote "Fly" to keep their brand name
| and then continued in blog-writing mode as a result
| OJFord wrote:
| Amazing, that was exactly my (only) reaction too.
|
| Oh, this must be genuine, hip CEO who has disabled
| autocapitalisation (or fought it) and not bothered to
| capitalise anything anyone else with similar education level
| would ... Until the next paragraph!
|
| If I am ever in such a position and make such a decision I
| hereby give anyone and everyone permission to berate me and
| point me back to this comment and I'll correct myself
| thenceforth.
| kiwicopple wrote:
| you mock my capitalization and and in the same comment use
| "thenceforth". shame on you
| OJFord wrote:
| Is there a less 'wordy' way to say that? 'From then on'
| is longer and worse to type. That matters to me more on
| (autocapitalising) mobile than it perhaps does otherwise.
|
| I don't even really follow your point. Surely if I am
| 'too prescriptive' in wanting proper capitalisation, that
| is .. not exactly _in_ consistent with a 'wordy' choice
| of word anyway?
| tptacek wrote:
| Based on insight I have gained from the deep corporate
| relationship that has grown between our firms I can say
| with some confidence that he is fucking with you.
| bmelton wrote:
| Mathematically speaking, 'henceforth' is shorter
| OJFord wrote:
| And linguistically speaking, has different meaning.
| toast0 wrote:
| If your goal is simply fewer bytes, I think you can leave
| out thenceforce and have a pretty similar meaning.
| satvikpendem wrote:
| Interesting, why doesn't Fly offer their own managed services
| and move up-market like DigitalOcean and others (and of course,
| the big cloud players)? I haven't heard of other companies
| coming in to collaborate on managing the hosted version of
| other companies' unhosted service.
| KRAKRISMOTT wrote:
| They lack the institutional DNA and culture for site
| reliability engineering. They have amazing system engineers
| and this is rather obvious from their blogposts. However
| their uptime numbers are frankly horrifying and in their
| support forums they spend a lot of time making customers do
| the work for them. They don't have the institutional culture
| to be running modern cloud infrastructure. Good engineers,
| terrible operators.
| tptacek wrote:
| They're related but distinct problem spaces. Craig Kerstiens
| is somewhere else on this thread talking about the work that
| went into Heroku's Postgres. Paul Copplestone can give you an
| earful about how hard Supabase was to build. We can talk your
| ears off about orchestration and Anycast networking. These
| are all big problems; they're not just features.
|
| I vividly remember hanging out on my back porch with Kurt as
| we were plotting out attached storage (we didn't even start
| out with storage!) and him telling me how hard it would be to
| replicate the kind of work Craig and Paul had done --- he'd
| know, after doing Compose.io! We had no illusions that we
| were going to provide that.
|
| Instead, we charted out a halfway point: "automated" but not
| "managed" Postgres, which is almost (not quite) just an
| application you deploy on top of Fly.io. You can see from my
| sibling comment how well that went. A managed database
| practice monitors and intervenes with database clusters in
| ways a fire-and-forget automated system doesn't. If you don't
| do all that work --- a whole (huge) company's worth of work
| --- you break peoples expectations, and they question your
| pedigree on message boards. :)
| swyx wrote:
| just here to say i love how well you take criticism.
| increases trust a lot because you are self aware yet
| provide a lot of competency proof points. you dont need it
| but thank you for what you do.
| tptacek wrote:
| Thank you! The team here gives us a lot to work with.
| Also: people dunking on us aren't wrong! We've made bets
| that represent particular spots on all sorts of
| reliability/predictability/performance/complexity axes.
| They are what they are, and it would be freaky if all of
| them paid off. We're wrong about some of this stuff. All
| we can do is be honest about what we're going for, and
| how that's going.
| jerrygoyal wrote:
| Hi, what are your thoughts on distributed SQLite? Do you see
| it's becoming the default choice instead of pgs in future?
| devoutsalsa wrote:
| ThePrimeagen (dev YouTuber:
| https://youtube.com/@ThePrimeagen) talks about liking Turso
| quite a bit, which is built on SQLite. I haven't tried it,
| but it sounds fun.
|
| https://turso.tech/
| jsierles wrote:
| Joshua from the Fly.io side here, happy to answer any questions
| about this integration.
| nicoburns wrote:
| Very excited for this. Aside from general reliability concerns
| (esp. around deploys - not helped by cryptic failure messages).
| Lack of managed Postgres has been the main thing keeping me off
| fly (I use it for a couple of side projects, but nothing big
| yet). And blob storage would probably be next on my list
| (basically stateful things are the things I want managed) so
| also excited to see that's being worked on.
|
| Do you have any details on pricing (for this new postgres
| offering) yet?
| kiwicopple wrote:
| (supabase team jumping in)
|
| this will follow our current pricing:
| https://supabase.com/pricing
|
| there could be some changes once we get through the testing
| phase and after Fly have blob storage, but they will probably
| be more favorable to you, the developer
| nicoburns wrote:
| EDIT: Oh, perhaps it follows this table?
| https://supabase.com/docs/guides/platform/compute-add-ons
|
| ---
|
| Original comment:
|
| Hmm... this seems to say 8GB storage, 250GB bandwidth and 7
| day backups (not point in time) for $25/month? + 7 day
| point in time backups for an extra $100/month? But it
| doesn't seem to mention anything about the CPU or RAM specs
| of the database server? And it also seems to bundle a bunch
| of other things, so it's hard to know how much of that is
| for the database server...
|
| Will it be possible to choose different sized servers? And
| to buy managed Postgres on it's own without running the
| whole of superbase?
| pier25 wrote:
| So $25 per month/DB and then usage based?
|
| Is bandwidth also paid considering it will be only used in
| the internal Fly network?
| philip1209 wrote:
| I'm excited to switch to this - I've been building Booklet on
| Fly.io and their Postgres to make the app distributed [1]. The
| biggest problem for me has been the Fly postgres configuration.
| Specifically, Fly puts HAProxy in front of Postgres with a 30m
| connection timeout [2], which keeps killing connections. This
| should be manageable, but I'm seeing quirks in the connection
| terminations that don't seem to align with their docs and keep
| causing instability.
|
| Question for the team members here - will the new PG still have
| the same HAProxy in front?
|
| [1] https://www.contraption.co/essays/booklet-architecture/
|
| [2] https://community.fly.io/t/postgresql-connection-issues-
| have...
| kiwicopple wrote:
| it will have our own connection pooler[0] for Postgres
| connections instead of HAProxy, as well as PostgREST[1] for
| REST
|
| [0] https://supabase.com/blog/supavisor-postgres-connection-
| pool...
|
| [1] https://postgrest.org/
| plondon514 wrote:
| Very excited about this. We're currently running a large db on
| fly and looking for a managed pg. We're a fully Elixir shop and
| this couldn't have come at a better time. Congrats to both teams!
| candiddevmike wrote:
| Where's the SLA?
| nextworddev wrote:
| I heard Supabase has known to have scaling issues beyond
| prototype projects, can anyone comment who has production
| experience with it?
| tmountain wrote:
| It's Postgres running on AWS, so it should scale as well as one
| would expect with that combination. What issues are you
| referring to specifically?
| kiwicopple wrote:
| yes it has the same scaling parameters as RDS (and soon we'll
| have a few other ways to scale beyond)
|
| perhaps OP is talking about this[0] post, which is mostly
| about struggles with local development. we addressed this
| here[1]
|
| here is an app this week that I imagine is larger than most:
| https://twitter.com/seif_ghezala/status/1734967554659983418
|
| [0] https://news.ycombinator.com/item?id=36004925
|
| [1] https://news.ycombinator.com/item?id=37059401
| refulgentis wrote:
| Wow Pika runs on Supabase!?! Congrats. 800K!? I can
| officially tell myself to stop worrying about scaling
| before launching, probably even for a couple years
| leros wrote:
| I understand the neatness of fly.io's distributed VMs. Can
| someone explain how Fly Postgres is different than a traditional
| managed Postgres on something like Heroku.
| tptacek wrote:
| We wrote a blog post about this:
|
| https://fly.io/blog/how-we-built-fly-postgres/
| leros wrote:
| If I'm understanding correctly, Fly Postgres isn't too
| different from something like Postgres on Heroku? It's a
| single instance/cluster in a single location.
| craigkerstiens wrote:
| I don't think that's correct at all. Heroku Postgres has a
| central control plane that is monitoring availability and
| orchestrating things. There are continual health checks
| that go back to Heroku. In the event of unavailability it
| sets off a page to the on-call engineer to investigate if
| systems haven't restored availability.
|
| My understanding of Fly Postgres is they put a lot into the
| tools to orchestrate, but there is not centralized
| monitoring and in the event of a failure it is up to you to
| realize and remediate.
|
| Disclaimer: Was part of the team that built Heroku
| Postgres, and know the Fly team pretty well but don't
| personally use Fly Postgres so it's my understanding from
| the team. We've had a number of customers leverage Crunchy
| Bridge (build by a lot of the original Heroku Postgres
| team) use us for the managed Postgres connected to fly.io
| via Tailscale.
| tptacek wrote:
| Yeah! One way to think about it that is almost (not
| perfectly) correct is that you could build and run all of
| Fly Postgres yourself; it's almost just a Fly App
| configuration.
| leros wrote:
| I think you're talking mostly about Heroku being a
| managed service while Fly Postgres is unmanaged. It
| sounds like the new managed Postgres in partnership with
| Supabase is managed in a similar way where Supabase would
| handle health checks and all that?
|
| Management is a huge difference of course, but I was
| mostly asking about the database from the point of view
| of a user of the database. It doesn't sounds like Fly
| Postgres is doing anything like running your database
| globally - you still have single instance of the
| database.
|
| Apologies if I'm missing some details. I intentionally
| try to stay out of the technical devops type stuff. I'm
| the kind of person who just pays Heroku for a Postgres
| and doesn't think much about it after that.
| tptacek wrote:
| For what it's worth, Fly Postgres isn't single-instance
| or single-location. (But it's also not managed, which is
| a big deal).
| satvikpendem wrote:
| How does that work? Does Fly just give you the logins for
| all of the Postgres servers you provision and you manage
| it yourself?
| tptacek wrote:
| See the blog post linked upthread.
| craigkerstiens wrote:
| I think a bit of confusion on Fly Postgres vs. the
| Supabase offering. The earlier was unmanaged on Fly
| infra.
|
| I'm not sure the full details on supabase as it's more
| recent.
|
| This is a pretty good breakdown of various database
| providers and in particular a lot paired with Fly -
| https://dancroak.com/webstack/
| smallerfish wrote:
| Very nice. I've never really liked Supabase's network
| restrictions setup
| (https://supabase.com/docs/guides/platform/network-
| restrictio...), and IIRC when I looked at it there was some weird
| issue exposing the Fly IP for your app to Supabase, and locking
| Supabase down to it. Having Supabase actually within the Fly
| network is great. Congrats to both teams.
| loloquwowndueo wrote:
| The issue here would be that fly.io doesn't guarantee outgoing
| IP addresses to be consistent so you can't allowlist based on
| originating IP. This is mentioned in fly.io networking
| documentation.
| tptacek wrote:
| Oh, wow, I forgot that this (database ingress filtering) was
| a big motivator for the engineering project we were
| considering for giving apps persistent outbound IP addresses,
| a project I loathe and now have another arrow in my quiver
| with which to shoot it down.
|
| I stand alone athwart all efforts to introduce dynamic
| routing protocols here.
|
| (I could still lose this argument if there are comparably
| important use cases).
| Alacart wrote:
| Why do you loathe it? Coming from someone who kind of wants
| it.
| tptacek wrote:
| Infra engineering is the most important, hardest
| engineering practice in the company. I'm not one, and the
| people who want to do this are. So leave a lot of space
| here for me just being wrong.
|
| I've had a bit of experience implementing IGP-style
| routing --- both as a "user" (a Cisco network engineer
| doing multi-area OSPF) and a developer (of a custom link-
| state IGP) --- and it left me pretty terrified of the
| failure modes here, which feel pretty similar to those of
| Raft/Paxos consensus, or of the SWIM Gossip consensus we
| do in our Consul replacement, Corrosion, which has its
| own challenges. If there are "innovation tokens", there
| are also "distributed consensus" tokens, and my basic
| take is I don't think we should spend them for such a
| marginal feature.
|
| Here I am litigating an internal company discussion on HN
| (this is simultaneously bad, and an exercise in us just
| being an open book). I remind you of the initial
| paragraph here, which lays out plainly that the people in
| our company who disagree with me are smarter than me. A
| really good use case could end my reign of static routing
| reign of terror!
| loloquwowndueo wrote:
| One can try to push Fly.io to implement dynamic routing
| to get persistent outbound IP addresses. This is full of
| foot guns and dragons.
|
| Or one can push the other vendor to implement vpn support
| on their side such that their service can talk to Fly.io-
| hosted ones in an end-to-end secure channel so the actual
| services can trust that a lot more. This is the solution
| often suggested in Fly.io forums.
|
| If the other vendor is sending ostensibly private traffic
| over the public internet and relying on a combination of
| "the Postgres protocol is safe and passwords are strong
| enough" and "oh but they really aren't so we will limit
| this service to talk to only one IP address" it seems to
| me it's them who should be nudged towards a more secure
| and versatile solution.
| trevor-e wrote:
| I looked into Supabase a while back but left confused on how to
| do a basic REST API. They auto-generate an API to interact with
| the tables you create which sounds neat, but like, where does the
| business logic live? I then checked out their edge functions but
| it wasn't clear if they are meant to be used that way since the
| examples are more oriented for tasks. Seems like I'm not
| understanding something simple here.
| Mortiffer wrote:
| core element is https://postgrest.org/en/stable/ . I use this
| in production in large corporate projects on k8s. For a large
| number of use cases you can put logic into stored procedures
| SQL. PG can also do JS or Py stored procedures but you get a
| better developer experience if your logic code is deployed
| through regular CI/CD containers or functions (we use both
| extensively together depending on cost trade offs either one.)
|
| Supabase suggests you to use their DENO serverless functions
| which is cool and all but i think most people would rather
| deploy node functions on cloudflare for webprojects.
|
| That being said the target customer group are those that want
| to have 99% of their logic in JS frontend. Backend just does
| CRUD and Auth.
| trevor-e wrote:
| Interesting, thanks for the info. I thought they were
| targeting mobile developers since they claim to replace
| Firebase, but sounds like a mobile app API wouldn't fit their
| platform very well. That explains why I was very confused
| trying to use their mobile SDK for iOS lol.
| refulgentis wrote:
| AFAIK Supabase serverless is Cloudflare, or at least I
| thought...
| pcnc wrote:
| It previously ran on Deno, but now we run our own edge
| runtime!
|
| https://github.com/supabase/edge-runtime
| fulafel wrote:
| It seems Supabase only supports JS and PL/pgSQL, not Python
| or the rest of PG languages. But still you could use compile-
| to-js languages like ClojureScript.
| pcnc wrote:
| Unfortunately python for Postgres is only available as an
| untrusted language extension, which can provide avenues for
| things like privilege escalation[0]
|
| We've decided to only bundle trusted language extensions so
| that there is a balance between flexibility when it comes
| to users writing their own procedures, all while
| maintaining security.
|
| [0] https://www.postgresql.org/docs/current/plpython.html
| fulafel wrote:
| Oh, interesting. Is it related related to any inherent
| property of CPython? As there's also trusted Perl, Tcl,
| Lua etc: https://wiki.postgresql.org/wiki/PL_Matrix
| yesimahuman wrote:
| You can access the database from anywhere (client and server
| depending on your config). I use nextjs so many of my database
| calls are in Next serverless functions. However, I'll probably
| explore moving some of that logic to supabase functions to keep
| them as close as possible to the database, but I haven't wanted
| to move to deno. When you access supabase on the server you can
| either use their PostgREST features (basically an autogenerated
| REST API on top of your db which the supabase clients use), or
| just access Postgres directly though a typical pg lib
| trevor-e wrote:
| Got it, thanks. This actually fits one of my side projects
| really well, will have to try it out with NextJS.
| kiwicopple wrote:
| (supabase team)
|
| you have a few options:
|
| 1. connect to Postgres like you do with any other Postgres
| database. Supabase is just postgres
|
| 2. connect to PostgREST, the autogenerated REST API that you
| mention
|
| 3. connect using Edge Functions (Deno)
|
| Most people are fine with 1. You can use 2 & 3 if you want to,
| they are just another tool in the shed
| zoogeny wrote:
| One thing to keep in mind which I found using Postgrest
| interface: you will end up having to put logic into stored
| procedures. The rest APIs are actually very convenient for
| aggregating data like joins, but I started to get stuck as soon
| as I wanted things like transactions. I also found that Row
| Level Security (RLS) for role based access was a chore and the
| developer experience of it left much to be desired.
|
| If your DB needs are simple then the REST api is very
| convenient. But if you are planning anything of complexity then
| you'll have to bone up on your PL/pgsql or go for a regular db
| connection instead.
| phanimahesh wrote:
| What about plv8? Write js in postgres! I tried it out once
| for a project of relatively low complexity for
| maintainability reasons, nobody else knew pl/pgsql. Worked
| great.
| zoogeny wrote:
| I'm sure it works fine, its just another thing to add to
| your stack (in some sense). Just a few days ago I saw a
| comment where a business owner was bragging about how his
| entire business was run on SQL stored procedures. He had
| made the technical decision to move all business logic into
| the database using triggers and stored procedures. That is
| certainly an option. Otherwise, you end up with a mix of
| business logic between your code and your database. This
| can cause confusion and can lead to hard-to-debug systems.
|
| In that sense, if you are like the business owner who
| swears by SQL and making the database the core business-
| logic layer of your system, then you might even appreciate
| that Postgrest forces you do move that kind of logic into
| the database. It is just something to be aware of before
| you make the decision so you that you aren't surprised when
| it happens.
| refulgentis wrote:
| I'm really curious about more of your perspective on RLS: I
| spent most of my career on mobile and rely heavily on
| Supabase to give me server superpowers. RLS _seems_ really
| cool to me (just write a one liner to define access rules as
| simple as complex as you need!), but I'm guessing I'm missing
| something. Especially because I don't actually have users yet
| ;)
| niklasd wrote:
| About the "as complex as you need": RLS can get slow very
| quickly for aggregate queries, and is hard to debug (since
| query planner doesn't work smoothly with RLS).
|
| We have a dashboard that displays aggregated stats for our
| admin users, and we hit serious performance issues with
| ~600 users with our first implementation. This repo helped
| us: https://github.com/GaryAustin1/RLS-Performance
| zoogeny wrote:
| Have a look at the supabase-community claims repo [1].
| NOTE: this is for ACL type permissions where you want to
| provide granular access to a wide range of services.
|
| This stuff is "really cool" but just keep in mind that it
| is pretty advanced. And exactly as another commenter noted
| in this thread, it is possible to destroy your performance
| if you need to join on other tables in an extended version
| of this kind of RLS policy.
|
| In this repo, the logic is simply "if a claim exists on the
| JWT then grant access". But in a lot of cases you may want
| to do something like "if this user is an owner of <row in
| another table> then grant access". That can require a join
| to that other table. That logic can get even more complex,
| for example, you might want to say "allow the user access
| to this row if they are an owner of the project". So you
| have to do more work to join from a child table, to a
| project table, to the user table, etc.
|
| These operations are in _addition_ to any work you might be
| doing in the actual query that is executed. I have no idea
| if the query planner can recognize you are doing the same
| joins in the RLS as the main query and optimize that away.
| But at any rate, every single policy invocation (on every
| single query) will be executing this logic.
|
| These are all considerations if you are planning more
| advanced access policies to your data. If all you need is a
| binary "can access"/"cannot access" then basic RLS policies
| may be fine. But once you get into even moderately complex
| scenarios your policies are likely to balloon in complexity
| and you'll be writing a fair amount of PL/pgsql and
| fighting with testing and validating.
|
| 1.https://github.com/supabase-community/supabase-custom-
| claims...
| teaearlgraycold wrote:
| Yeah I'm sticking with RDS and such
| cpursley wrote:
| What we do is much of the business logic in Postgres (triggers,
| constraints, etc). But then there's all the other stuff like
| external integrations, etc.
|
| We handled that by having an event system built on the Postgres
| WAL that we use like a callback system.
|
| I put together a little library in Elixir (that originally
| started out as forked Supabase realtime) for this:
|
| https://github.com/cpursley/walex
|
| Recently added the ability to configure WalEx to forward events
| to webhooks or EventRelay (so you don't need to know Elixir).
| OJFord wrote:
| Ha, this is weird. I noticed this earlier today in Fly docs and
| was surprised I'd missed it on HN (as surely it would've
| appeared). I didn't realise it was new.
|
| My second reaction was that it's crazy there's 'Postgres by Fly'
| and 'Postgres by Supabase' in the sidebar. There isn't even an
| (obvious, or that I noticed) comparison offered. If I'm deploying
| an app on Fly and want postgres, what do I use?
|
| (Personally I think if I use Fly and want a dbms I'll use LiteFS
| distributed SQLite, and if you do want postgres I _think_ the
| answer is that Fly vs Supabase is basically unmanaged vs.
| managed.)
| xena wrote:
| Fly.io employee here. Go with Supabase if you want a managed
| database. Fly.io Postgres is unmanaged. This is the key
| difference, yes.
| nomilk wrote:
| Can you ELI5 the difference? Especially any sharp edges +
| pros/cons. I suspect I'm not alone coming from managed
| postgres (e.g. heroku or similar) and am open minded to
| unmanaged but don't want to unknowingly make a poor infra
| decision.
| tptacek wrote:
| Managed database offerings give you a Postgres URL and you
| just go to town. They take care of scaling and monitoring.
| Fly Postgres is automated, but not managed: our tooling
| will boot up a Postgres cluster for you, at a specified
| size, but it's not going to do so much database-level
| monitoring that you can forget about the database and just
| assume it's always healthy regardless of your usage.
|
| If your expectations are set from Heroku's Postgres, you
| want a managed database. You're going to notice that Fly.io
| people aren't going to push you to Fly Postgres. You want
| to be reasonably comfortable with clustered Postgres to
| choose our unmanaged Postgres over Supabase's --- maybe not
| so comfortable that you'd set it up yourself (it's
| automated, after all, and does a bunch of cluster
| orchestration for you) --- but enough to do your own
| monitoring, sizing, and provisioning.
|
| Lots and lots and lots of people rely on Fly Postgres, and
| it's a reasonable option. If I was doing a low-level
| project, like an individual service in a larger ensemble,
| or an expiriment or side project or a spike, I'd probably
| use Fly Postgres. But if I was launching a whole product on
| top of Fly.io, and a Postgres database was my system of
| record, I'd want Supabase.
| TobyTheDog123 wrote:
| These two companies have pricing models that I just absolutely
| hate.
|
| On one end of the spectrum you have Supabase - a very Vercel-
| esque "developer platform" with tiered offerings that ensure that
| you're paying more than you're using.
|
| On the other end of the spectrum you have Fly - a very Lambda-
| esque offering with hyper-specific per-second per-memory per-cpu
| pricing where you'll probably end up paying too little and
| getting performance hits.
|
| I really do not understand why people would do either when things
| like Cloudflare Workers (et al) exist. Why do people still want
| to worry about scaling?
| revskill wrote:
| It's all about Posgresql ecosystem, DX and other addons.
| alphabettsy wrote:
| Trying running any random Docker container you might need on
| Cloudflare workers and you'll see why.
|
| Fly has really straightforward monthly pricing that's not
| Lambda like at all, but CF workers pricing model is more
| similar to Lambda between the two.
| solatic wrote:
| Cloudflare Workers doesn't offer a Postgres option. At most,
| there's Hyperdrive to connect to Postgres hosted elsewhere, and
| even then Hyperdrive is essentially a connection pooler, with
| all the additional restrictions that places on you.
|
| It's also unlikely that Cloudflare will offer a true Postgres
| option; their whole ethos is that anything you deploy is
| deployed globally, whereas relational databases enforce having
| a single server as a definition of truth. But I'd love to be
| proven wrong here.
| TobyTheDog123 wrote:
| You're right - I should have clarified that I'm talking about
| new projects - as in "Why would someone choose Postgres over
| one of these distributed SQLite providers for a new project?"
|
| (I'm sure those use-cases exist, but I'm not sure if they
| exist inside the use-cases Supabase supports)
| tehlike wrote:
| There is lots of money to be saved by using hetzner + hetzner-k3s
| + cloudnativepg or crunchydata postgres operator.
| rywalker wrote:
| cloudnativepg is great, we're using it as a foundational
| component to Tembo's OSS and Cloud services (tembo.io).
| revskill wrote:
| k3s is hard to manage, it required a bunch of money there.
| tehlike wrote:
| It's really not that bad.
| tptacek wrote:
| Say more? Super interested in any backstory or insight here
| b/c rsns.
| surfmike wrote:
| how is fly.io reliability these days?
| lawik wrote:
| Mostly better from the client project where we run them.
| Haven't had as many disruptions since shifting from their nomad
| offering to machines.
|
| I have some reservations about machines but none of them have
| been actual problems yet :)
| mrkurt wrote:
| I would love to hear your reservations. We've made some
| choices for simplicity that I expected us to have to engineer
| around, but a surprising number of them haven't been problems
| in practice. In short, I have reservations too.
| canadiantim wrote:
| Is there any thought towards adopting ParadeDB within supabase?
| Or atleast using the extensions they develop?
| rywalker wrote:
| We're actively working towards adding ParadeDB to Tembo Cloud
| (cloud.tembo.io) - feel free to message us in app to get alpha
| access.
|
| i expect supabase will do it too at some point.
| philippemnoel wrote:
| ParadeDB developer here -- we're developing a way for users to
| no zero-ETL sync between any managed Postgres and ParadeDB, so
| that you can get a dedicated search node on Postgres without
| slowing down your production DB. We expect this will be the
| primary way in which people use ParadeDB in the future.
|
| That being said, we understand that for startups it might be
| easier to have pg_bm25 directly within their production
| database, especially if data volume is small. We're actively
| open to working with other Postgres-as-a-Service providers in
| the space to make this possible :)
| timenova wrote:
| > Fly machines don't have network-attached storage, so we treat
| any data in Fly volumes as ephemeral.
|
| I've never used AWS, and I'm not too familiar with network-
| attached storages in general either. Can someone explain what's
| the exact difference between a Fly volume and a network-attached
| storage offered by other providers?
|
| IIRC, once you create a Fly volume, you can move it to another
| server in the same region? So aren't they technically network-
| attached storages?
| tptacek wrote:
| No. Fly Volumes are attached NVME storage; they're anchored to
| the physical host they're created on.
|
| Under the hood, we can migrate a volume from one physical to
| another (the way we do this is pretty interesting and we'd
| write it up, except that to date the process has played an
| outsized role in the work sample testing we use for all of our
| technical roles). I don't think we've surfaced that, much, yet,
| but we will this year.
|
| We back Fly Volumes up to off-network block storage at regular
| intervals (more announcements coming shortly here too).
|
| But a really basic thing to understand about Fly Volumes is
| that they're _not_ SAN storage, and they 're _not_
| intrinsically reliable the way, say, S3 is. They appear in Fly
| Machines as simple ext4 filesystems, and if you need
| reliability /durability/replication, you need to provide it at
| the application layer. That's how Fly Postgres works: clusters
| of read replicas, all of which can take over and assume write
| leader role if they need to. This makes sense because with Fly
| Postgres the only purpose to which the underlying volume is put
| is running a Postgres database, which already provides
| durability/replication.
|
| This is, for instance, why we print a big red warning on the
| console if you ask us to create a single-node Postgres cluster.
|
| I think we're going to roll out stuff in the next couple
| quarters that will offer new options on the reliability/perf
| spectrum. But I don't think they'll involve us running SAN
| drives --- servers that just expose block devices over iSCSI or
| whatever.
| timenova wrote:
| Thanks for the detailed reply!
|
| Looking forward to more storage-related announcements and the
| blog posts.
| stevoski wrote:
| What's the latency like, when hosting your app on Fly, and your
| db on Supabase?
|
| Is there some coordination happening to make sure they are in the
| same data centre?
|
| Edit: I should have read the article. All explained in the first
| paragraphs that the db is hosted on Fly infrastructure.
| jnsaff2 wrote:
| For those who did not get the SupaFly reference a fun watch:
| https://www.youtube.com/results?search_query=joe+cartoon+sup...
| twsted wrote:
| Does anyone know if there is a comparison somewhere for the
| various Postgres offerings (eg heroku, aws, crunchydata, fly,
| supabase, etc)), both managed and unmanaged, with features and
| pricing?
| jadayesnaamsi wrote:
| I am particularly interested in a comparaison between this new
| one from Supabase/Fly and the one from Neon.
| cpursley wrote:
| Main thing I want to know: which of the managed Postgres
| services allow for logical replication.
|
| I love Heroku, render and neon is promising - but non allow
| access to the WAL.
| kevinbrolly wrote:
| Hey, supabase employee here. We allow you to use logical
| replication -
| https://supabase.com/docs/guides/database/replication
|
| AFAIK all the others mentioned do not allow logical
| replication as you noted.
| SahAssar wrote:
| Can I ask what your use-case is for logical replication on
| something like neon?
| cpursley wrote:
| So I can run something like Supabase or WalEx which
| subscribe to WAL changes.
| SahAssar wrote:
| Ah, gothca. I've mostly used triggers and LISTEN/NOTIFY
| for those things, so haven't tried the WAL methods.
___________________________________________________________________
(page generated 2023-12-16 23:02 UTC)