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

FAT32

@Murv said:

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

so much generous!

You know, it is more blessed to give than to receive

Just my 2 cents

beanman109

@FAT32 said:

@Murv said:

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

so much generous!

You know, it is more blessed to give than to receive

Just my 2 cents

I'd love to receive your KS-A if you want to feel double blessed

Murv

@FAT32 said: Just my 2 cents

oloke

@Murv said:

@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

oh god..

don't pay this

bdl

@oloke said:

@Murv said:

@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

oh god..

don't pay this

pay this instead

Murv

Am I like the richest Onidel user right now?
@onidel you don't happen to allow account transfers right

Neoon

@FAT32 said:

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

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

How generous of you, gonna declare bankrupcy tomorraw?

oloke

@Murv said:

Am I like the richest Onidel user right now?
@onidel you don't happen to allow account transfers right

Selling your account would be prohibited by our ToS. (if that's what you meant )

Neoon

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

YABS plz.

Murv

@Neoon said: YABS plz.

Can you give me a Postgres port of YABS?

Neoon

@oloke said:

@Murv said:

Am I like the richest Onidel user right now?
@onidel you don't happen to allow account transfers right

Selling your account would be prohibited by our ToS. (if that's what you meant )

MJJ not gonna be happy, they gonna do it anyway though and then complain here on LET.

Murv

@oloke said: Selling your account would be prohibited by our ToS.

Neoon

@Murv said:

@Neoon said: YABS plz.

Can you give me a Postgres port of YABS?

We could make a port with ChatGPT.
"Convert to Postgres, make no mistakes"

Smigit

So having a play, just of the UI really. Add/delete DB’s, users, do some stuff and restore backup and roll it back etc

Three minor things both on the backups page.

1) Super minor but the phase "Automatic daily backups of your database.” maybe could be “database(s)” given it may apply to multiple.

2) Would be good to show when the daily backups are actually being run, and since we have per-customer VMs backing this, possibly even give the option to customise the time of day, assuming it wouldn’t interfere with your managed maintenance windows.

3) When restoring have the confirmation prompt prioritise showing the localised control-panel time of the backup being restored, as it is displayed on the list of backups. The name of a timestamped file is displayed in the conformation prompt that doesn’t match anything on the prior page where I hit ‘restore’. Show the time that’s on the list of backups on the confirmation popup so it’s easy to determine I’m restoring to the correct time and not trying to do an offset for time zones on the fly.

On the users page

3. When creating users you can initially set a password yourself, or leave it blank to have it generated. But the UI won’t let you manually change the password to something else of your choosing after the fact, you can only change it to a random value moving forward. Perhaps allow both manually setting a new password, or have it auto generated, to match the options when creating the account initially.

4. Users Accounts and Backup Rollback - Bit of weirdness here. If you make a backup, then go and edit the password for a user account, and then do a database rollback, one of the following occurs
   a) If the user is not the initial Default user, after the rollback the ‘password’ can no longer be unveiled in the UI and the message 'Password changed externally’ is displayed. I assume this is an artefact of the rollback process, but ‘external’ is actually the Onidel control panel here as I’m not using any extra tools myself. Expected the password to still be visible, probably. I can however hit ‘Reset Password’ to get a new one and the UI then works.
   b) If the user account was the Default user, it looks to revert to a prior password but not necessarily the one that was in use either at the time of the backup or the time of the restore, just some other value from a point in time. I thought it was the servers original account password for a while there but seems after a few changes, I’m now getting some other value.
   I think in both cases I was expecting probably to have the password from the time of the backup, or it not to be changed, and no messaging about external processes.

onidel

@dodheimsgard said:
Is your postgress db HA?

it is HA at VM level, no replica option yet

plumberg

@onidel @oloke - is it possible to host a Postgres admin ui from within the panel to run queries/ check schema? It will be a big help for quick checks

plumberg

@onidel @oloke

Unable to connect to NY DB:

connection timeout expired
Multiple connection attempts failed. All failures were:
- host: 'beta-ny-pg17.XX.us-east-1.mdb.onidel.cloud', port: '56995', hostaddr: '2602:XXXX:ZZZ:YY::1': connection failed: connection to server at "2602:XXX:ZZZ:YY::1", port 56995 failed: FATAL: server login failed: wrong password type
- host: 'beta-ny-pg17.XX.us-east-1.mdb.onidel.cloud', port: '56995', hostaddr: '192.209.XX.209': connection timeout expired

Created ticket also

onidel

@plumberg said:
@onidel @oloke

Unable to connect to NY DB:

connection timeout expired
Multiple connection attempts failed. All failures were:
- host: 'beta-ny-pg17.XX.us-east-1.mdb.onidel.cloud', port: '56995', hostaddr: '2602:XXXX:ZZZ:YY::1': connection failed: connection to server at "2602:XXX:ZZZ:YY::1", port 56995 failed: FATAL: server login failed: wrong password type
- host: 'beta-ny-pg17.XX.us-east-1.mdb.onidel.cloud', port: '56995', hostaddr: '192.209.XX.209': connection timeout expired

Created ticket also

try again :-)

plumberg

@onidel said:

@plumberg said:
@onidel @oloke

Unable to connect to NY DB:

connection timeout expired
Multiple connection attempts failed. All failures were:
- host: 'beta-ny-pg17.XX.us-east-1.mdb.onidel.cloud', port: '56995', hostaddr: '2602:XXXX:ZZZ:YY::1': connection failed: connection to server at "2602:XXX:ZZZ:YY::1", port 56995 failed: FATAL: server login failed: wrong password type
- host: 'beta-ny-pg17.XX.us-east-1.mdb.onidel.cloud', port: '56995', hostaddr: '192.209.XX.209': connection timeout expired

Created ticket also

try again :-)

works now

pluto

@oloke when can I try this product in HoChiMinh?

oloke

@pluto said:
@oloke when can I try this product in HoChiMinh?

Yes, please open a ticket

allthemtings

@Murv said:

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

so much generous!

Thread ruined. X9 him and remake

pyCyber

Hoping to run timescaledb on top of it.

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

Please do not nerf writes. My use case is write-heavy. Ingesting trade data and storing it for analytics over on TimescaleDB.

pyCyber

@pyCyber said:
Hoping to run timescaledb on top of it.

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

Please do not nerf writes. My use case is write-heavy. Ingesting trade data and storing it for analytics over on TimescaleDB.

Is extension supported? Wanting to run TimescaleDB
https://github.com/timescale/timescaledb

onidel

@Smigit said:
So having a play, just of the UI really. Add/delete DB’s, users, do some stuff and restore backup and roll it back etc

Three minor things both on the backups page.

1) Super minor but the phase "Automatic daily backups of your database.” maybe could be “database(s)” given it may apply to multiple.

2) Would be good to show when the daily backups are actually being run, and since we have per-customer VMs backing this, possibly even give the option to customise the time of day, assuming it wouldn’t interfere with your managed maintenance windows.

3) When restoring have the confirmation prompt prioritise showing the localised control-panel time of the backup being restored, as it is displayed on the list of backups. The name of a timestamped file is displayed in the conformation prompt that doesn’t match anything on the prior page where I hit ‘restore’. Show the time that’s on the list of backups on the confirmation popup so it’s easy to determine I’m restoring to the correct time and not trying to do an offset for time zones on the fly.

On the users page

3. When creating users you can initially set a password yourself, or leave it blank to have it generated. But the UI won’t let you manually change the password to something else of your choosing after the fact, you can only change it to a random value moving forward. Perhaps allow both manually setting a new password, or have it auto generated, to match the options when creating the account initially.

4. Users Accounts and Backup Rollback - Bit of weirdness here. If you make a backup, then go and edit the password for a user account, and then do a database rollback, one of the following occurs
   a) If the user is not the initial Default user, after the rollback the ‘password’ can no longer be unveiled in the UI and the message 'Password changed externally’ is displayed. I assume this is an artefact of the rollback process, but ‘external’ is actually the Onidel control panel here as I’m not using any extra tools myself. Expected the password to still be visible, probably. I can however hit ‘Reset Password’ to get a new one and the UI then works.
   b) If the user account was the Default user, it looks to revert to a prior password but not necessarily the one that was in use either at the time of the backup or the time of the restore, just some other value from a point in time. I thought it was the servers original account password for a while there but seems after a few changes, I’m now getting some other value.
   I think in both cases I was expecting probably to have the password from the time of the backup, or it not to be changed, and no messaging about external processes.

1. thanks, will update the text there.
2. yes backup schedule will be configurable. the service actually has point-in-time recovery enabled, so you can restore the service to either the last backup or your choosen time.
3. see 2.
4. we'll allow setting a new password manually.
5. i'll try to reproduce your observation. about external maybe we need to just reword it to password changed, since we only keep the latest password to compare and do not know who changed it.

much appreciate your feedbacks

@pyCyber said:
Hoping to run timescaledb on top of it.

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

Please do not nerf writes. My use case is write-heavy. Ingesting trade data and storing it for analytics over on TimescaleDB.

@pyCyber said:

@pyCyber said:
Hoping to run timescaledb on top of it.

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

Please do not nerf writes. My use case is write-heavy. Ingesting trade data and storing it for analytics over on TimescaleDB.

Is extension supported? Wanting to run TimescaleDB
https://github.com/timescale/timescaledb

keen on understand your resource utilisation for this case so we can adjust the specs accordingly. we'll be adding some extensions to the default installation

machinetto

I'm curious to try this, because cautious because no price has been announced.

For my low traffic setup, a postgres container is serving me well. Using a managed service would be nice if that means, I don't need to worry about scaling, backups, optimization etc.

My only concern is that when pricing is announced and I'm assuming it costs a little more than the smallest VPS, then it would have been more economical to continue using my self hosted containers. If I try out the managed DB now, I wouldn't want to deal with migration again if my specific/limited use case (at the moment) does not justify the pricing.

I wish Onidel the best. They've been a very good provider from my limited experience and interaction with them.

Smigit

Ok, sweet. Set up a first app. Going smoothly.

@onidel said:
5. i'll try to reproduce your observation. about external maybe we need to just reword it to password changed, since we only keep the latest password to compare and do not know who changed it.

Yep. Might be something to just cover with documentation somewhere.

So is the plan to roll out Postgres initially and add other db’s later on, or will redis/mysql etc come along in the beta period?

Also will plan upsize/downsize be supported? Assume that’s on the cards. Imagine storage increases in particular.

trewq

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

Literally based on the size of the animal so it's the only logical way to name things

onidel

@Smigit said:
Ok, sweet. Set up a first app. Going smoothly.

@onidel said:
5. i'll try to reproduce your observation. about external maybe we need to just reword it to password changed, since we only keep the latest password to compare and do not know who changed it.

Yep. Might be something to just cover with documentation somewhere.

So is the plan to roll out Postgres initially and add other db’s later on, or will redis/mysql etc come along in the beta period?

Also will plan upsize/downsize be supported? Assume that’s on the cards. Imagine storage increases in particular.

other dbs will come with their own beta periods. downgrade is not supported.

also, the service will be billed hourly once we're out of beta. This is mainly due to how we want the restore functionality to work in the end:

• a restore will effectively "fork" into a new service instance. We back up the entire database server/cluster rather than individual databases, so restoring would overwrite all databases. In most cases, users only want to restore a single database.
• creating a new instance with the restored data avoids impacting the existing prod db, and allows users to safely play with PITR.

onidel

a few updates based on some early feedbacks and requests:

Extensions

Some common extensions are installed by default and can be enabled/disabled directly from the UI

Metrics

Active queries, query statistics and service logs are available in the panel as well

Custom configurations

Some DB configurations can be updated directly in the panel