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

Smigit · April 6

@onidel said:

@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.

yep attaching it might do the trick.

HostBilby · April 6

@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?

I’m ok with it if they can make my whmcs database fasterer and betterer!

notONIDEL

Smigit · April 6

@HostBilby 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?

I’m ok with it if they can make my whmcs database fasterer and betterer!

That’d be the real easter miracle.

onidel · April 6

@FAT32 said:

@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:

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?

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?

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)?

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?

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)?

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.

Good call out. Those specs aren't final and we'll adjust before GA.

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 :-)

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.

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.

all specs will be available when we reach GA. we're trying to see how people utilise the resources.

we thought about having everything in a same big boy as well, but it comes with many things that we do not like:

single point of failure. if a DB server / machine itself dies for some reasons, all customers will be impacted.
same thing applies to daily operations - one minor config change can impact all customers.
hard to make access control right.
downtime when doing maintenance
and etc

why wouldn't we take advantage of our existing HA virtualisation infra? it gives us better control, isolation, reliablity and for most use cases I think the performance difference is nelegible - just need to size the resources right.

plumberg · April 6

Wooooooot
Good going @onidel @oloke

onidel · April 6

@HostBilby 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?

I’m ok with it if they can make my whmcs database fasterer and betterer!

notONIDEL

hah i just wanted to promote those australian buddies and GPT gave me the list of names. i may actually rename it to better represent the compute power.

HostBilby · April 6

@onidel said:

@HostBilby 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?

I’m ok with it if they can make my whmcs database fasterer and betterer!

notONIDEL

hah i just wanted to promote those australian buddies and GPT gave me the list of names. i may actually rename it to better represent the compute power.

Always in good company ❤️

FAT32 · April 6

@onidel said:

@HostBilby 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?

I’m ok with it if they can make my whmcs database fasterer and betterer!

notONIDEL

hah i just wanted to promote those australian buddies and GPT gave me the list of names. i may actually rename it to better represent the compute power.

How much do I need to pay to name the largest plan Le Dino

FAT32 · April 6

@onidel said:

@FAT32 said:

@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:

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?

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?

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)?

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?

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)?

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.

Good call out. Those specs aren't final and we'll adjust before GA.

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 :-)

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.

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.

all specs will be available when we reach GA. we're trying to see how people utilise the resources.

we thought about having everything in a same big boy as well, but it comes with many things that we do not like:

single point of failure. if a DB server / machine itself dies for some reasons, all customers will be impacted.

same thing applies to daily operations - one minor config change can impact all customers.

hard to make access control right.

downtime when doing maintenance

and etc

why wouldn't we take advantage of our existing HA virtualisation infra? it gives us better control, isolation, reliablity and for most use cases I think the performance difference is nelegible - just need to size the resources right.

Understood, I am just trying to understand the difference between me running on a VM on Onidel (or other platform) vs this managed DB.

In this case it feels like a VM with PostgreSQL template, but without the SSH and I still have to manually handle with performance tuning etc. Of course, some future benefits could include auto scale up / down CPU depends on load etc, which makes it more attractive as a "managed" DB service.

plumberg · April 6

Plans for managed

Sql server
duck db

Ability to move data between locations?
Read only replicas?
Geo replicate data among different locations?

@onidel @oloke

Levi · April 6

How much do you know about postgre in order to offer managed service?

Neoon · April 6

We need a teleportation feature, eh I mean migration feature.
One click and my databaz ein Sydney is teleported to Murica.

rpqu · April 6

@Neoon said:
We need a teleportation feature, eh I mean migration feature.
One click and my databaz ein Sydney is teleported to Murica.

Should have asked virtono

Neoon · April 6

@rpqu said:

@Neoon said:
We need a teleportation feature, eh I mean migration feature.
One click and my databaz ein Sydney is teleported to Murica.

Should have asked virtono

@virtono can you provide your expertise please?

onidel · April 6

@FAT32 said:

@onidel said:

@FAT32 said:

@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:

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?

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?

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)?

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?

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)?

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.

Good call out. Those specs aren't final and we'll adjust before GA.

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 :-)

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.

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.

all specs will be available when we reach GA. we're trying to see how people utilise the resources.

we thought about having everything in a same big boy as well, but it comes with many things that we do not like:

single point of failure. if a DB server / machine itself dies for some reasons, all customers will be impacted.

same thing applies to daily operations - one minor config change can impact all customers.

hard to make access control right.

downtime when doing maintenance

and etc

why wouldn't we take advantage of our existing HA virtualisation infra? it gives us better control, isolation, reliablity and for most use cases I think the performance difference is nelegible - just need to size the resources right.

Understood, I am just trying to understand the difference between me running on a VM on Onidel (or other platform) vs this managed DB.

In this case it feels like a VM with PostgreSQL template, but without the SSH and I still have to manually handle with performance tuning etc. Of course, some future benefits could include auto scale up / down CPU depends on load etc, which makes it more attractive as a "managed" DB service.

that's a fair point. The main difference is that we handle things like installation, initial tuning, encryption, upgrades, backups, and patching - along with any additional configurations and features we roll out over time. Basically rather than managing the database as infrastructure, you can focus more on using it as a service. You pay to get your time and peace of mind back.

onidel · April 6

@Levi said:
How much do you know about postgre in order to offer managed service?

can't say we know better than anyone else here, but we have been running postgre in prod for more than 5yrs.

emgh · April 6

did mr ococke code this

sorry meant ococke

fuck, sorry, meant to say ococke

i give up

emgh · April 6

@onidel said:

@Levi said:
How much do you know about postgre in order to offer managed service?

can't say we know better than anyone else here, but we have been running postgre in prod for more than 5yrs.

nobody knows postgres better than me

Smigit · April 6

@onidel said:

@Levi said:
How much do you know about postgre in order to offer managed service?

can't say we know better than anyone else here

Feel free to tell people you know more than me

beanman109 · April 6

@emgh said:

@onidel said:

@Levi said:
How much do you know about postgre in order to offer managed service?

can't say we know better than anyone else here, but we have been running postgre in prod for more than 5yrs.

nobody knows postgres better than me

what about postgres peter

dodheimsgard · April 6

Is your postgress db HA?

Murv · April 6

halo, thx @oloke @onidel
tis a dream come tru

beanman109 · April 6

@Murv said:
halo, thx @oloke @onidel
tis a dream come tru

are you gonna pay that or

Murv · April 6

@beanman109 said: are you gonna pay that or

me waiting for payday
too large to pay right now

FAT32 · April 6

@Murv said:
halo, thx @oloke @onidel
tis a dream come tru

@oloke can I transfer $0.02 account credit to this account

FAT32 · April 6

Also @Murv can you use my referral code so I get 15% of your $0.01

emgh · April 6

@beanman109 said:

@emgh said:

@onidel said:

@Levi said:
How much do you know about postgre in order to offer managed service?

can't say we know better than anyone else here, but we have been running postgre in prod for more than 5yrs.

nobody knows postgres better than me

what about postgres peter

i said nobody

Murv · April 6

@FAT32 said: @oloke can I transfer $0.02 account credit to this account

so much generous!

Murv · April 6

@FAT32 said: Also @Murv can you use my referral code so I get 15% of your $0.01

i don't think their crypto gateway is ready for this yet
@oloke full fix dis plz

Smigit · April 6

@Murv said:
halo, thx @oloke @onidel
tis a dream come tru

-90OFF

Howdy, Stranger!

Categories

In this Discussion

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

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

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

Comments