Onidel Managed PostgreSQL Database | Free Early Access (Beta) | SG AU NL US VN

onidel

Hello everyone,

We are excited to announce the beta rollout of our new product - Managed Databases 🎉

At this stage, we support PostgreSQL (v16 and v17), with a solid set of features to get you up and running quickly.

🚀 Features

• PostgreSQL v16 & v17 supported
• IPv4 and IPv6 support
• SSL/TLS enabled by default
• Encryption at rest (LUKS2)
• Daily automated backups (7-day retention) + manual backups
• User and database management (including SQL import via control panel)
• IP Whitelisting.
• Available in all locations: 🇺🇸 New York, 🇳🇱 Amsterdam, 🇸🇬 Singapore, 🇦🇺 Sydney, 🇻🇳 Ho Chi Minh

💡 Access & Pricing

During this beta phase, access is granted via ticket:
👉 Submit ticket

There is no cost during beta, and we are currently finalising pricing for GA - it will be competitive.

Available plans during beta:

🙌 Feedback & Rewards

We'd love your feedback, suggestions, and bug reports during this beta phase.

Participants will be eligible for rewards (credit / free service / merch / ... ) when we reach GA - feel free to share your screenshots and feedback here so we can include you!

📸 Screenshots

Here's a quick look at the product:

❓ Questions?

Feel free to ask here, DM me, or reach out to @oloke - we're happy to help!

lala_th

First one

onidel

@lala_th said:
First one

are you a bot or something lol

beanman109

can you host my sqlite database

mjjshow

wow, nice

Arirang

How are VACUUM and autovacuum processes handled in your managed environment?

Are these processes automatically managed by your platform, and can customers adjust related settings such as thresholds, scale factors, or scheduling?

If dead tuples and table bloat accumulate before VACUUM runs, is that space included in the billed storage usage?

In other words, is storage billing based on the physical disk space allocated on the instance, including table bloat, or only on the active data size?

Obelous

@onidel said: we are currently finalising pricing for GA - it will be competitive.

onidel

@beanman109 said:
can you host my sqlite database

yes managed sqlite is in progress

@Arirang said:
How are VACUUM and autovacuum processes handled in your managed environment?

Are these processes automatically managed by your platform, and can customers adjust related settings such as thresholds, scale factors, or scheduling?

If dead tuples and table bloat accumulate before VACUUM runs, is that space included in the billed storage usage?

In other words, is storage billing based on the physical disk space allocated on the instance, including table bloat, or only on the active data size?

autovacuum is enabled by default and you can adjust settings using psql.

db data is stored on a separate disk and it is basically billed on the disk level usage.

rpqu

Nice. Any plan of doing global database?

Smigit

It looks like you guys went to the plan pages at @HostBilby and named the SQL tiers after their offerings. No one seems to be picking the Australian snakes and spiders that will kill you for some reason.

Looks interesting but. Are there other databases along with SQLite planned?

onidel

@rpqu said:
Nice. Any plan of doing global database?

wdym?

@Smigit said:
It looks like you guys went to the plan pages at @HostBilby and named the SQL tiers after their offerings. No one seems to be picking the Australian snakes and spiders that will kill you for some reason.

Looks interesting but. Are there other databases along with SQLite planned?

mysql and redis probably. do you have anything in mind?

Obelous

@onidel said: wdym?

I assume he means replication of some sort?

Smigit

@onidel said:

@Smigit said:
It looks like you guys went to the plan pages at @HostBilby and named the SQL tiers after their offerings. No one seems to be picking the Australian snakes and spiders that will kill you for some reason.

Looks interesting but. Are there other databases along with SQLite planned?

mysql and redis probably. do you have anything in mind?

I had MySQL in mind

suyadi92

Finally, singapore. Noice

rpqu

@onidel said:

@rpqu said:
Nice. Any plan of doing global database?

wdym?

Multi-reg db. Something like Google cloud spanner

FAT32

Oh my oh my I want one

onidel

@rpqu said:

@onidel said:

@rpqu said:
Nice. Any plan of doing global database?

wdym?

Multi-reg db. Something like Google cloud spanner

ah no there is no plan for that yet

rpqu

@onidel said:

@rpqu said:

@onidel said:

@rpqu said:
Nice. Any plan of doing global database?

wdym?

Multi-reg db. Something like Google cloud spanner

ah no there is no plan for that yet

Hmm, I thought I had told @oloke to push @onidel into making such product

Murv

can i pay $0.01 to get access instead of free

FAT32

@Murv said:
can i pay $0.01 to get access instead of free

Same here and make it recurring forever

onidel

@Murv said:
can i pay $0.01 to get access instead of free

@FAT32 said:

@Murv said:
can i pay $0.01 to get access instead of free

Same here and make it recurring forever

if you participate in this run and share your results then it is likely that you'll get a free service

btw didn't see you around lately @FAT32 !

FAT32

@onidel said:

@Murv said:
can i pay $0.01 to get access instead of free

@FAT32 said:

@Murv said:
can i pay $0.01 to get access instead of free

Same here and make it recurring forever

if you participate in this run and share your results then it is likely that you'll get a free service

btw didn't see you around lately @FAT32 !

Ya you know... tech layoff and stuff

Time to move our production DB to Onidel and sue for millions when it goes down /s

allthemtings

Looks nice! Onidel numba 1

nghialele

Wow nice

onidel

@FAT32 said:

@onidel said:

@Murv said:
can i pay $0.01 to get access instead of free

@FAT32 said:

@Murv said:
can i pay $0.01 to get access instead of free

Same here and make it recurring forever

if you participate in this run and share your results then it is likely that you'll get a free service

btw didn't see you around lately @FAT32 !

Ya you know... tech layoff and stuff

Time to move our production DB to Onidel and sue for millions when it goes down /s

can't wait

Smigit

Gonna shoot a message over later…want to have a play. Got some idling servers I’ll move something to.

Out of interest, have you built in to the UI support for upgrading of databases, so you can for example go from PostgreSQL 16 to 17 as your application stack is updated? Might be handy, especially if it can fit in with the 7 day backup retention to allow a downgrade in the scenario something has gone wrong and to automate a backup on commencement of the upgrade, etc.

FAT32

Anyway serious question for now:

1. How is the IOPS determined? I assume each managed DB is stored at their own Ceph-like storage at the backend and the I/O will be restricted to that particular DB?
2. Most DB requests should be read-heavy, granted most of the common read should ideally be cached / fit in memory, does it makes sense to have higher read IOPS than write IOPS?
3. There doesn't seem to be mention of CPU limitation, does that means a user could theoretically hog the whole CPU for their unoptimised queries (while still remain within the disk I/O)?
4. 25 connections might be a bit limited for a managed DB (eg. Let's assume a simple application with 10-20 connections per application node, that means it will hit the bottleneck with just ~2 nodes), can this be further bumped to say 100?
5. What will be the bandwidth limitation like? Can user utilise free private bandwidth for requests within the same DC (such as VM products with Onidel)?

Smigit

Looking at the screenshots, can the whitelisting UI maybe include the selection of one or more Onidel VPS and have the IP ranges auto configured when selecting that existing host, and auto updated if for any reason the IP address changes in the future (such as the host IP is reallocated due to maintenance, or people make changes via the VPS servers networking tab to enable/disable IPv6 or to an ‘additional IP'). Saves jumping into those settings to manually copy changes over, avoids fat finger errors and is generally just a tad quicker to get going.

Also curious about private bandwidth that Fat32 mentioned for same region.

onidel

@Smigit said:
Gonna shoot a message over later…want to have a play. Got some idling servers I’ll move something to.

Out of interest, have you built in to the UI support for upgrading of databases, so you can for example go from PostgreSQL 16 to 17 as your application stack is updated? Might be handy, especially if it can fit in with the 7 day backup retention to allow a downgrade in the scenario something has gone wrong and to automate a backup on commencement of the upgrade, etc.

we haven't explored that yet, but it's definitely something we are planning to look into. If there's a paved road for upgrade, we'd aim to support it directly in the UI. Our goal is to simplify those stuffs as much as possible.

@FAT32 said:
Anyway serious question for now:

1. How is the IOPS determined? I assume each managed DB is stored at their own Ceph-like storage at the backend and the I/O will be restricted to that particular DB?
2. Most DB requests should be read-heavy, granted most of the common read should ideally be cached / fit in memory, does it makes sense to have higher read IOPS than write IOPS?
3. There doesn't seem to be mention of CPU limitation, does that means a user could theoretically hog the whole CPU for their unoptimised queries (while still remain within the disk I/O)?
4. 25 connections might be a bit limited for a managed DB (eg. Let's assume a simple application with 10-20 connections per application node, that means it will hit the bottleneck with just ~2 nodes), can this be further bumped to say 100?
5. What will be the bandwidth limitation like? Can user utilise free private bandwidth for requests within the same DC (such as VM products with Onidel)?

1. Each managed database service runs on its own dedicated VM. The database data is stored on a separate disk attached to that VM, and the IOPS limit applies to this disk - not to individual databases within it. You're free to create as many databases as you'd like on your instance.
2. Good call out. Those specs aren't final and we'll adjust before GA.
3. You can use the full vCPU allocation for your instance. If you're consistently maxing it out, we'll reach out to suggest upgrading your plan :-)
4. We definitely can. As mentioned all those specs are not final, and we will adjust it as we go. We are trying to balance client connections / vcpu / ram / disk space for each plans.
5. Yes, you'll be able to attach your database to your VPC for private bandwidth between your DB and VMs in the same DC. This isn't available just yet.

onidel

@Smigit said:
Looking at the screenshots, can the whitelisting UI maybe include the selection of one or more Onidel VPS and have the IP ranges auto configured when selecting that existing host, and auto updated if for any reason the IP address changes in the future (such as the host IP is reallocated due to maintenance, or people make changes via the VPS servers networking tab to enable/disable IPv6 or to an ‘additional IP'). Saves jumping into those settings to manually copy changes over, avoids fat finger errors and is generally just a tad quicker to get going.

Also curious about private bandwidth that Fat32 mentioned for same region.

we could support that, but I'm not sure if I like it. From security perspective, I generally prefer whitelisting rules to be explicit - ACLs shouldn't change automatically without a user-initiated action.

if you are using Onidel VMs, you will soon be able to attach the DB to your VPC, which can help simplify things in many cases.

FAT32

@onidel said:

@Smigit said:
Gonna shoot a message over later…want to have a play. Got some idling servers I’ll move something to.

Out of interest, have you built in to the UI support for upgrading of databases, so you can for example go from PostgreSQL 16 to 17 as your application stack is updated? Might be handy, especially if it can fit in with the 7 day backup retention to allow a downgrade in the scenario something has gone wrong and to automate a backup on commencement of the upgrade, etc.

we haven't explored that yet, but it's definitely something we are planning to look into. If there's a paved road for upgrade, we'd aim to support it directly in the UI. Our goal is to simplify those stuffs as much as possible.

@FAT32 said:
Anyway serious question for now:

1. How is the IOPS determined? I assume each managed DB is stored at their own Ceph-like storage at the backend and the I/O will be restricted to that particular DB?
2. Most DB requests should be read-heavy, granted most of the common read should ideally be cached / fit in memory, does it makes sense to have higher read IOPS than write IOPS?
3. There doesn't seem to be mention of CPU limitation, does that means a user could theoretically hog the whole CPU for their unoptimised queries (while still remain within the disk I/O)?
4. 25 connections might be a bit limited for a managed DB (eg. Let's assume a simple application with 10-20 connections per application node, that means it will hit the bottleneck with just ~2 nodes), can this be further bumped to say 100?
5. What will be the bandwidth limitation like? Can user utilise free private bandwidth for requests within the same DC (such as VM products with Onidel)?

1. Each managed database service runs on its own dedicated VM. The database data is stored on a separate disk attached to that VM, and the IOPS limit applies to this disk - not to individual databases within it. You're free to create as many databases as you'd like on your instance.
2. Good call out. Those specs aren't final and we'll adjust before GA.
3. You can use the full vCPU allocation for your instance. If you're consistently maxing it out, we'll reach out to suggest upgrading your plan :-)
4. We definitely can. As mentioned all those specs are not final, and we will adjust it as we go. We are trying to balance client connections / vcpu / ram / disk space for each plans.
5. Yes, you'll be able to attach your database to your VPC for private bandwidth between your DB and VMs in the same DC. This isn't available just yet.

Thanks, that clear things up. My understanding of "Managed DB" is more of I don't have to worry too much about the resources such as RAM as well, but that's a bit different than what I expect.

I didn't noticed there's mention of vCPU, I guess it will be great if you mention that as well as I thought it is all in the same big instance, performance will most likely suffer a bit more as it is executed in a virtualisation container instead of bare metal.