4 ms·

Nikita - CEO of Neon here. We intended to post this at the launch next month, but since it here, I'm happy to answer any questions. We have been hard at work a

by nikita 4y ago

Nikita - CEO of Neon here. We intended to post this at the launch next month, but since it here, I'm happy to answer any questions. We have been hard at work and looking to open the service to the public soon.

zeusly 4y ago
Hey Nikita, could you maybe put some more legal information on the webpage? I'm trying to find out if you're a company and where you are located. Is there no legal entity behind this? Do you have a privacy policy?
- mattashii 4y ago
  The company is Neon, Inc., which is registered in the USA. We're a remote company, with a significant portion of the developers being located in Europe. Privacy policy and related stuff will be ready when we publish the public beta, which we expect to happen soon.
  - nikita 4y ago
    Yep, Delaware corp with top tier US investors. I'm in the Bay Area. Heikki is in Finland. Stas is in Cyprus. Majority of engineering is in Europe, some in the US and Canada. Postgres is a global phenomenon.
akmodi 4y ago
Hey Nikita! I was just looking at the docs but I was a bit confused about what the various compute instances were doing. Do they all serve reads and writes? If so, is there data partitioning or does this support distributed transactions?
- nikita 4y ago
  Various compute instances are different endpoints to separate databases. So for now it's single writer system. You can get a lot of power out of a 128 core compute node. In the future will will also spin up extra compute to scale reads. In the future after that future we will introduce data partitioning - we have a cool design for it, but one step at a time.
  - akmodi 4y ago
    Ah got it thanks! And what's the consistency on the instances that serve reads? Super interested in this space since we're always looking for ways to evolve our pg!
    - akmodi 4y ago
      Ignore this. I misread your previous reply (￣ー￣；
code_biologist 4y ago
Cool stuff! Is PostGIS support difficult?
- nikita 4y ago
  It's supported. The beauty of the architecture is that it doesn't break plugins.
  - tuukkah 4y ago
    Could you include it in the tech preview? https://neon.tech/docs/cloud/compatibility/ https://neon.tech/docs/cloud/compatibility/
    - kelvich 4y ago
      Sure, we will
avinassh 4y ago
This is really exciting and thank you for making it open source. I am still trying to wrap my head around the Neon, but is there any design document or architecture description? I want to learn more about the Neon storage engine and how it all fits together. Also, how do I get an invite code to try? edit: found this to get started - https://neon.tech/docs/storage-engine/architecture-overview/ https://neon.tech/docs/storage-engine/architecture-overview/
- nikita 4y ago
  We will send you an invite code soon. This is a good start and also RFCs on github. We will be publishing more and more
  - alex-korr 4y ago
    Would love on as well.
timmg 4y ago
How “cheap” is it to create new db instances? I can imagine a world where it might be practical to have one master db for all of your customers/accounts. But a separate db instance for each customer’s data. Is that the kind of architecture you think might be workable with your system?
- nikita 4y ago
  It's cheap. Storage footprint is 15Mb and will be shrunk further. Min compute footprint is a 1 core container that shuts down when not used. We are already working with customers that do that. This is for sure a great use case for Neon.
  - unraveller 4y ago
    won't the tiny compute units on AWS have relatively slow storage? (no NVMe allowed for them I think) fine for small datasets that fit in ram but benchmarks are needed to show the bigger picture.
httgp 4y ago
Do you plan to solve for global data-at-the-edge availability? That to me is the killer feature for databases and one I’m direly in need of at work.
- nikita 4y ago
  Yes, we are discussing either simply using Postgres replication to move data to other regions and use our proxy to rout reads to the datacenter closer to the user (like fly.io). This will have issues with supporting more than ~5 regions. OR we can separate storage from replication and purpose build a multi-tenant replication service. This will support as many regions as you want (over 200) but it's more work. We will publish an RFC for that.

by nikita 4y ago

zeusly 4y ago

Hey Nikita, could you maybe put some more legal information on the webpage? I'm trying to find out if you're a company and where you are located. Is there no legal entity behind this? Do you have a privacy policy?

mattashii 4y ago
The company is Neon, Inc., which is registered in the USA. We're a remote company, with a significant portion of the developers being located in Europe. Privacy policy and related stuff will be ready when we publish the public beta, which we expect to happen soon.
- nikita 4y ago
  Yep, Delaware corp with top tier US investors. I'm in the Bay Area. Heikki is in Finland. Stas is in Cyprus. Majority of engineering is in Europe, some in the US and Canada. Postgres is a global phenomenon.

akmodi 4y ago

Hey Nikita! I was just looking at the docs but I was a bit confused about what the various compute instances were doing. Do they all serve reads and writes? If so, is there data partitioning or does this support distributed transactions?

nikita 4y ago
Various compute instances are different endpoints to separate databases. So for now it's single writer system. You can get a lot of power out of a 128 core compute node. In the future will will also spin up extra compute to scale reads. In the future after that future we will introduce data partitioning - we have a cool design for it, but one step at a time.
- akmodi 4y ago
  Ah got it thanks! And what's the consistency on the instances that serve reads? Super interested in this space since we're always looking for ways to evolve our pg!
  - akmodi 4y ago
    Ignore this. I misread your previous reply (￣ー￣；

code_biologist 4y ago

Cool stuff! Is PostGIS support difficult?

nikita 4y ago
It's supported. The beauty of the architecture is that it doesn't break plugins.
- tuukkah 4y ago
  Could you include it in the tech preview? https://neon.tech/docs/cloud/compatibility/ https://neon.tech/docs/cloud/compatibility/
  - kelvich 4y ago
    Sure, we will

avinassh 4y ago

This is really exciting and thank you for making it open source. I am still trying to wrap my head around the Neon, but is there any design document or architecture description? I want to learn more about the Neon storage engine and how it all fits together. Also, how do I get an invite code to try? edit: found this to get started - https://neon.tech/docs/storage-engine/architecture-overview/ https://neon.tech/docs/storage-engine/architecture-overview/

nikita 4y ago
We will send you an invite code soon. This is a good start and also RFCs on github. We will be publishing more and more
- alex-korr 4y ago
  Would love on as well.

timmg 4y ago

How “cheap” is it to create new db instances? I can imagine a world where it might be practical to have one master db for all of your customers/accounts. But a separate db instance for each customer’s data. Is that the kind of architecture you think might be workable with your system?

nikita 4y ago
It's cheap. Storage footprint is 15Mb and will be shrunk further. Min compute footprint is a 1 core container that shuts down when not used. We are already working with customers that do that. This is for sure a great use case for Neon.
- unraveller 4y ago
  won't the tiny compute units on AWS have relatively slow storage? (no NVMe allowed for them I think) fine for small datasets that fit in ram but benchmarks are needed to show the bigger picture.

httgp 4y ago

Do you plan to solve for global data-at-the-edge availability? That to me is the killer feature for databases and one I’m direly in need of at work.

nikita 4y ago
Yes, we are discussing either simply using Postgres replication to move data to other regions and use our proxy to rout reads to the datacenter closer to the user (like fly.io). This will have issues with supporting more than ~5 regions. OR we can separate storage from replication and purpose build a multi-tenant replication service. This will support as many regions as you want (over 200) but it's more work. We will publish an RFC for that.