Re: Multiple SQLITE databases vs one BIG PostgreSQL database

2011-05-04 Thread Brian Bouterse
SQlite has issues with efficiently serving multiple database connections
simultaneously.  It is still ACID compliant, but the performance can crawl
with multiple users.  I think this has to do with the locking being
filesystem based.  That being said it sounds like your db's would all be
used by independent clients so this probably isn't an issue for you.  If you
need to in the future relate data that is isolated in individual sqlite
databases then it would have been better to have things in one place.  To
recap, IMHO, if you have a portability requirement, a single user at a time
per db, and no need to relate data in between these small independent
databases then go with SQlite.

If you decide to go with a big db, go with Postgres.  It's the best in the
business for the money and complexity.  I have used mysql a lot before too,
and I do not recommend it.  Oracle is complicated and closed.

Best,
Brian

On Wed, May 4, 2011 at 6:32 AM, VoodooH  wrote:

> Hello guys,
>
> We currently have a desktop software that uses a sqlite embedded
> database. We are now gonna develop the online version for our software
> and we need your opinion on these matters :
>
> 1. We were thinking of giving our users the option to switch between
> the online and offline version of the software by simply moving the
> sqlite database between the two applications. This would save us a lot
> of dev time for now, but we are afraid that we will have scalability
> issues later. There will be around 10 000 users at least, so at least
> 10 000 sqlite independent databases. The other option of course is a
> very big PostgreSQL database. There will be millions, if not tens of
> millions of records in this BIG database.
>
> Which version do you recommend between the two ? Should we go for the
> fast development sqlite version or build a database from scratch and
> make some import/export tools between the two apps ?
>
> 2. If we were to go for the big database version, which one yould you
> recommend between PostgreSQL, MySQL and ORACLE ?
>
> 3. Any ideas on how it would be best to implement a sync tool between
> the desktop and the SaaS if we go for the PostgreSQL version ?
>
> Thank you very much !
>
> Regards,
>  Radu
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>


-- 
Brian Bouterse
ITng Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: Multiple SQLITE databases vs one BIG PostgreSQL database

2011-05-04 Thread David Goehrig
I'd recommend going the PostgreSQL route.  I have a number of apps that use the 
architecture where Postgres is running in a federated multi-master setup with 
client side SQLite db used as local cache. Building a data sync service between 
the two using django to ship models via a RESTishAPI degerates into a trivial 
task. 

For one large deployment with tens of millions of documents with tens of 
millions of users we have no problems on a handfull of commodity servers. 

-=-=- d...@nexttolast.com -=-=-

On May 4, 2011, at 6:32 AM, VoodooH  wrote:

> Hello guys,
> 
> We currently have a desktop software that uses a sqlite embedded
> database. We are now gonna develop the online version for our software
> and we need your opinion on these matters :
> 
> 1. We were thinking of giving our users the option to switch between
> the online and offline version of the software by simply moving the
> sqlite database between the two applications. This would save us a lot
> of dev time for now, but we are afraid that we will have scalability
> issues later. There will be around 10 000 users at least, so at least
> 10 000 sqlite independent databases. The other option of course is a
> very big PostgreSQL database. There will be millions, if not tens of
> millions of records in this BIG database.
> 
> Which version do you recommend between the two ? Should we go for the
> fast development sqlite version or build a database from scratch and
> make some import/export tools between the two apps ?
> 
> 2. If we were to go for the big database version, which one yould you
> recommend between PostgreSQL, MySQL and ORACLE ?
> 
> 3. Any ideas on how it would be best to implement a sync tool between
> the desktop and the SaaS if we go for the PostgreSQL version ?
> 
> Thank you very much !
> 
> Regards,
>  Radu
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: Multiple SQLITE databases vs one BIG PostgreSQL database

2011-05-04 Thread Brian Bouterse
You're probably right about using Postgres.  Postgres is rock solid,
scalable, and easy to use.

I've recently had a need to create a bridge between PostgreSQL and SQlite.
 Primarily because I use SQlite in my dev environments, but use PostgreSQL
in production.  I have been planning to write something to allow all data to
be moved back and forth.  It sounds like you have a data sync service.  Any
thoughts on open sourcing that code?  Anyone else know of a project that
already does this?

Thanks,
Brian

On Wed, May 4, 2011 at 9:02 AM, David Goehrig  wrote:

> I'd recommend going the PostgreSQL route.  I have a number of apps that use
> the architecture where Postgres is running in a federated multi-master setup
> with client side SQLite db used as local cache. Building a data sync service
> between the two using django to ship models via a RESTishAPI degerates into
> a trivial task.
>
> For one large deployment with tens of millions of documents with tens of
> millions of users we have no problems on a handfull of commodity servers.
>
> -=-=- d...@nexttolast.com -=-=-
>
> On May 4, 2011, at 6:32 AM, VoodooH  wrote:
>
> > Hello guys,
> >
> > We currently have a desktop software that uses a sqlite embedded
> > database. We are now gonna develop the online version for our software
> > and we need your opinion on these matters :
> >
> > 1. We were thinking of giving our users the option to switch between
> > the online and offline version of the software by simply moving the
> > sqlite database between the two applications. This would save us a lot
> > of dev time for now, but we are afraid that we will have scalability
> > issues later. There will be around 10 000 users at least, so at least
> > 10 000 sqlite independent databases. The other option of course is a
> > very big PostgreSQL database. There will be millions, if not tens of
> > millions of records in this BIG database.
> >
> > Which version do you recommend between the two ? Should we go for the
> > fast development sqlite version or build a database from scratch and
> > make some import/export tools between the two apps ?
> >
> > 2. If we were to go for the big database version, which one yould you
> > recommend between PostgreSQL, MySQL and ORACLE ?
> >
> > 3. Any ideas on how it would be best to implement a sync tool between
> > the desktop and the SaaS if we go for the PostgreSQL version ?
> >
> > Thank you very much !
> >
> > Regards,
> >  Radu
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>


-- 
Brian Bouterse
ITng Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.



Re: Multiple SQLITE databases vs one BIG PostgreSQL database

2013-08-24 Thread Roman R
This applies to situations when lots of write requests are being made, 
right? Otherwise, SQLite can handle lots of concurrent connections.


On Wednesday, May 4, 2011 7:40:18 AM UTC-5, bmbouter wrote:
>
> SQlite has issues with efficiently serving multiple database connections 
> simultaneously.  It is still ACID compliant, but the performance can crawl 
> with multiple users.  I think this has to do with the locking being 
> filesystem based..

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.